Re: [boost] boost development process / scope

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-05-06 14:08:49

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.
> 
> You should also keep in mind that of all Boost.Build work, only a fraction
> is Boost.Build core work. For example, funny naming rules for built libraries
> is not a core functionality of *any* build system. Likewise, Boost.Python
> support is not something you get for free when using make. 

Yes, I agree. Again, I didn't mean to criticise the tools themselves. But
even if the ultimate problems stem from incorrect use of these tools, it's
caused by those tools being moving targets.
There were fixes to the boost.python build system even after the freeze,
and they ultimately were caused by bbv2 being relatively new and not yet well
understood and tested by a broad community. In contrast, 'make' is a very well
known and understood tool, and people know its limitations and how to navigate
around them. (For avoidance of doubt: this is *not* an argument to use 'make'
instead. My point merely is that using new and experimental tools makes for
a very fragile development platform.)

>> As a boost developer I'd rather not worry about infrastructure. At least
>> not more than absolutely necessary.
> 
> That's a good abstract goal. Would you clarify when and how you 
> was forced to "worry about infrastructure" and what concrete steps do you 
> suggest to be taken? "be decoupled as much as possible" is not 
> a concrete step as far as I'm concerned.

Sure. As you know there have been some problems very late in the release
cycle with boost.python tests, where accidentally a wrong python interpreter
was dragged in. Only very few people (inculding a core bbv2 developer) understood
the problem well enough to be able to come up with a fix.

Regards,
                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...