Boost logo

Boost :

Subject: Re: [boost] [1.46.1] Release candidates available
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2011-03-10 15:39:33


On 3/10/2011 1:14 PM, Henrik Sundberg wrote:
> 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.

Seems easy and reasonable. I'd likely make the comment more specific,
like the trac comments. Something like: (authorized by beman). That way
there's an audit trail.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

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