Re: [boost] boost development process / scope

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-06 11:04:26

Vladimir Prus wrote:
> Stefan Seefeld wrote:
> 
>> Vladimir Prus wrote:
>>
>>> I doubt Boost.Build can be decoupled much more. We have our own mailing
>>> list, our own issue tracker, our own webpage and our own releases.
>>>
>>> The only coupling is that Boost.Build lives in Boost CVS, and I'm not
>>> sure if that's bad thing, or good thing.
>> Technically that may be correct. However, as a matter of fact, boost.build
>> does get developed as part of boost. How long did it take to fix bbv2 bugs
>> *after* boost was converted to use it ? And how much is the slip of the
>> release due to problems in the infrastructure, as opposed to actual "C++
>> library code" ?
> 
> Nobody has the hard numbers. My gut feeling is that most of the slip 
> is not due to infrastructure problems, but other factors.

I don't think it was necessarily all problems, although there certainly were 
some.  Some of it is that making a change to something as core as the build 
system is like driving and aircraft carrier -- after someone says 'turn now', 
you have to wait a long time for the effect.  As I recall, it took a long time 
(months) to get all the regression testers transitioned to build v2.  There 
may have been a couple problems in there, but much of it was just the inertia 
of turning the big ship.  You know, people are traveling so they can't switch 
this week, then there's some pilot error it doesn't work and they run out of 
time, then something comes up and it drags into another week.  Your plans get 
blown apart by these little delays that add up.

And this is precisely why I'm suggesting 1.35 as new libs on the current 1.34 
base with some invitation only critical patches.  The only way I know to avoid 
these sort of unanticipated delays is to cut out the possibility of them 
cropping up by minimizing change.

BTW, this is why I very much favor removing support for the 'legacy compilers' 
as well.  If we eliminate them it removes another distraction that delays the 
release.  Each little individual patch or update to the expected results is a 
small thing, but in aggregate it adds up to substantial time. Effectively the 
value we are currently punishing the users of modern compilers by delaying 
functionality to wait for back porting to legacy compilers.  I'd rather ship 
1.35 right away and then let the legacy compiler changes catch up as needed. 
I think we did reach some agreement awhile back that we are going to eliminate 
some of the old compilers as a 1.35 requirement.

Jeff