That looks good, Nathan! I would add one more point after 1: 1. release preparation phase begins, PRs cut off date communicated. 1.5. PRs cut off date reached, no more PRs accepted On Mon, Feb 5, 2018 at 1:20 PM, Nathan Cutler <ncutler@xxxxxxx> wrote: >> Git branches remove any concern for >> "races". If someone pushed 100 commits to luminous, just create a >> different branch with exactly the commit(s) you *do* want and build from >> that. After everything is confirmed built, good, and tagged, push and >> merge it back into the luminous stream. > > > Sage makes a good point here, but I don't agree with the "remove any concern > for races" part. In practice, I'm envisioning that it would work like this > (substitute "jewel", "mimic" etc. for luminous): > > 1. release preparation phase begins > 2. lots of PRs/commits are merged into luminous > 3. release preparation phase ends with declaration of a "release candidate" > SHA1 > 4. a luminous-rc branch is created from this SHA1 > 5. QE phase begins > 6. all QE work takes place in luminous-rc > 7. any QE-related fixes are merged into luminous-rc > 8. QE phase ends with declaration of a "release" SHA1 which is (almost - see > below) guaranteed to be the tip of luminous-rc > 9. tag/build phase begins > 10. tag is applied to, and packages built from, tip of luminous-rc (as > usual, except luminous-rc instead of luminous) > 11. tag/build phase ends - point release is out > 12. luminous-rc is merged into luminous > > Granted, this does eliminate racing PRs in luminous, but it's still possible > for something to get merged into luminous-rc after step 8 and before step > 11, so the problem doesn't go away - it just gets less likely. > > 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
