Boost logo

Boost :

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


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