This is just my opinion: we should have a quick "bump commit + tag" Jenkins job that pushes the Git tag live as soon as possible. In particular we should not wait for packages to be build + signed + published on download.ceph.com before pushing the bump commit + tag live. Bumping and tagging in Git should take a minute or two, whereas building, signing, and rsync'ing all the packages for that tag takes hours. I think this time-intensive process causes the Git history to diverge for too long. - Ken On Fri, Feb 2, 2018 at 5:28 AM, Nathan Cutler <ncutler@xxxxxxx> wrote: > On 02/02/2018 01:05 PM, Alfredo Deza wrote: >>> >>> If we approximately stop accepting new PRs at the third week, ask leads >>> at >>> beginning of week 4 and go through only critical PRs for week 4; and go >>> to >>> QE in week5,6 we might be able to somewhat get to a more scheduled minor >>> releases. >> >> >> This might be a bit hard to deal with, how do you prevent a PR from >> getting merged? I've seen several times PRs getting merged at the last >> minute, >> with little to no testing, and breaking a release :( It hasn't >> happened much lately, but I don't know of a way to block all PRs for a >> period of time > > > Do we have a way of releasing a given SHA1 (which has passed QE) even when > additional PRs have been merged on top of it? > > IIRC in the past we could only release the tip of the named (jewel, > luminous) branch. That does indeed create a risk of PRs getting merged > post-QE and inadvertently finding their way into a release. > > Nathan > > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
