Boost logo

Boost :

Subject: Re: [boost] [1.45] REMINDER: Release branch is closed! (was: [1.45.0] Permission to merge trunk to release for (Polygon))
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-11-12 13:32:46


Eric Niebler wrote:
> This mistake is understandable and all too easy to make. Our process
> needs to be improved. It can't rely (as it currently does) on library
> maintainers following the developer list for hold-your-horses and
> all's-clear messages from the release managers. Suggestions? Can we
> lock the release branch? Trac is already smart enough to parse commit
> comments for bug numbers and close tickets. Can we make it smarter to
> block commits that aren't closing out a showstopper?

Is there a feature of revision control that allows a commit to go into a "pending approval" state where the release manager can review the commit message (or code changes if they feel the need) before allowing a commit to go through?

If not then our next best option is probably to lock the release branch and unlock it manually for specific users who have show stopper fixes that they want to commit and ask for permission on the dev list or directly from the release manager. Once the release branch is unlocked for a developer it remains unlocked because it is assumed they know what is going on because they asked for it to be unlocked and that they need it to remain unlocked so that they can address any regression failure caused by bad merges or whatever might go wrong with their commit. Once the release goes out the release branch can be unlocked for everyone until the next code freeze.

I wouldn't suggest a smarter solution that automatically detects fixes to showstopper bugs. It just sounds too complicated, which means it could lead to problems like people being confused how to commit their show stopper bug fixes or problems with it breaking when something changes in the future.

P.S. my regressions are passing now on the release branch.

Regards,
Luke


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk