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

From: David Abrahams (dave_at_[hidden])
Date: 2007-09-03 19:53:50

on Mon Sep 03 2007, Roland Schwarz <roland.schwarz-AT-chello.at> wrote:

> 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, 

This puts the release schedule completely at the mercy of developers
who have checked in unstable or "broken" code.  The release branch
should not start from a bunch of desired features without regard to
the code's stability.  It should start with the latest stable code
with little regard to what features it contains.

> 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.)

Sounds like a recipe for never releasing anything to me.

>> 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 :-( )

I do not believe that, given the necessary feedback mechanisms which
are currently not in place, Boost lacks the discipline to maintain a
clean trunk.

>> 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. 

That's why I said the list of *tested* release compilers.

> 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). 

I haven't noticed such a comment, even upon rereading your message.
But my initial reply was only responding to the top half of your
message.  I hadn't read the whole thing at that point.

> So I guess you rather prefer the current monolithic approach (for
> good reasons I believe).

I wouldn't draw any conclusions if I were you.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com