Re: [boost] [1.46.1] Release candidates available

Subject: Re: [boost] [1.46.1] Release candidates available
From: Henrik Sundberg (storangen_at_[hidden])
Date: 2011-03-10 14:14:39

On Thu, Mar 10, 2011 at 7:00 PM, Eric Niebler <eric_at_[hidden]> wrote:
> On 3/10/2011 8:19 PM, Beman Dawes wrote:
>> On Thu, Mar 10, 2011 at 5:30 AM, Eric Niebler <eric_at_[hidden]> wrote:
>>> I'll use this as another opportunity to advocate for physically locking
>>> the release branch when we're gearing up for a release. How many more
>>> times do we need to get burned? This was a lucky catch. Next time we
>>> might not be so lucky.
>>
>> I'm interested. How would do you see that working?
>
> How about this: when we're really close to release, the branch is locked
> so all commits are rejected. When someone wants to merge a fix, they ask
> permission. The release manager gives that one user commit access for 48
> hrs or whatever. The access automatically expires.
>
> I don't know if svn allows this kind of work flow. If not, then the
> branch can be locked and patches given to the release manager, who
> applies them himself. This is more work for the release manager, though.
>
> We'd need an svn expert to chime in.

I've proposed this earlier:
Add a precommit check, when the release branch is locked, that checks
that any commit in the release path has a commit comment that is
prefixed with e.g. "Authorized: ". If not, return error and write a
description of how to proceed to stderr.

The result is that no one commits by mistake, and that everyone can
understand what has happened and how to proceed.

/$