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