Re: [boost] Release procedure. Where do we go?

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-09-03 16:40:49

David Abrahams wrote:
> on Mon Sep 03 2007, Roland Schwarz wrote:
> 
>> 2)   branching out for release when the trunk is
>>       release-stable
> 
> Right there you've got a problem.  The problem is that the trunk will
> never become release-stable on its own if it is allowed to become "the
> bleeding edge."  So the release manager ends up freezing all checkins
> on the trunk while we try to stabilize it, which takes forever.

I admit that this is indeed bad wording, and not really what I had in 
mind. What I really meant was: branch if all features planned for the 
next release are in trunk. Then stabilize the branch, but do not wait 
with release until all bugs on all platforms are fixed, but allow for a 
gradual healing of the release branch until it comes to a halt because 
either no more bugs, or no interest from users. (Or no commits from 
commercial users that sell bug-fixing/platform-adaption to their 
customers.)

> The first problem, as I see it, is that the trunk is allowed to become
> broken, and there isn't a great deal of immediate pressure on the
> person who caused the breakage to fix it. 

This is question of socialization of the community. If it is common 
place to drive too fast, only police can help (and even that turns out 
not to work well :-( )

> If the person doesn't have
> access to the platform that broke, typically he just throws up his
> hands and says "somebody who knows this platform will have to help
> me," when instead he ought to back his changes out immediately.  We
> need our tools to be able to test branches so that won't happen.

Better tools will help here, no doubt.

> The second problem is that the list of tested release compilers has
> shifted around unpredictably, so people often can't find out when
> they've broken a platform until long after it's too late for an
> immediate reversion of their changes to the trunk.

Hmm, I guess I was one of those who made it appear as if the list was 
shifted around. In reality the list was rather fixed, but there simply 
nobody was testing a couple of toolsets. Starting these tests after a a 
while made a couple of regressions visible.

However this is not a problem with my proposed refinement of the 
procedure: Allow for gradual healing, i.e. release while stabilizing.
(Btw. Only lawyers might think that there is such a thing as bug free 
software )

But I have to admit that I do not have terribly much experience with 
management of such a huge code base as boost is. So perhaps arguing with 
you (the top level committing person) isn't bringing us closer to a 
solution.

May I instead ask some more pragmatic questions:

1) What should developers do until the new procedures are established?
    Should they try to stabilize branch ?
    Should they merge new code from trunk to RC_1_34_0 ?

2) Bug Fixes for 1.34.1
    Where should they go?
    RC_1_34_0 ?

Btw.: You didn't respond to my comment about modularization (ala. CPAN) 
vs. monolithic (ala. Linux Kernel). So I guess you rather prefer the 
current monolithic approach (for good reasons I believe).

Roland aka speedsnail