Re: [boost] boost development process / scope

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-05-04 12:24:42

Stefan Seefeld wrote:

> Here is a point I'd like to bring up in the context of
> the current discussion concerning the boost development
> process.
> I expect this issue to be highly controversial, hopefully
> it will result in a constructive discussion nonetheless...
> 
> Boost is all about modern C++ libraries. However, in the
> (very admirable) drive for perfection, developers not only
> strive for the ultimate C++ libraries, but also for perfect
> development tools. Thus, an integral part of boost is
> 
> * a build tool / infrastructure
> * a documentation harness
> * a testing harness
> 
> This, IMO, creates a number of problems :
> 
> * it heightens the barrier of entry for users as well as
>   contributors, as they need to learn new languages and new
>   tools (which, in general, are really understood only by
>   a handful of people)
> 
> * it creates considerable instability, as these tools have their
>   own development lifecycle. (I remember someone mentioning that
>   his documentation in the 1.34 branch depends on features of quickbook
>   in trunk, etc.)
> 
> * it dilutes the focus of boost itself
> 
> 
> So, in the spirit of 'lessons learned', I'd like to invite readers
> to imagine how life would be if the boost development would use
> existing (i.e. external) tools, if possible. (Example: docbook, rst,
> etc., instead of qbk; make instead of bjam, etc.)
> 
> Please don't get me wrong: I'm not criticising any of these tools
> per se. They may be wonderful, and have clear advantages over external
> tools. But please don't underestimate the advantage taken from a great
> user base, or the experience that went into all these tools over the
> years.
> 
> At least, I'd like to suggest that the development of these tools should
> be decoupled as much as possible from the development of the 'boost C++
> libraries'. That should benefit everybody: The boost development would
> draw on a much more stable development environment, and these tools would
> hopefully be recognized in domains outside of boost, helping them to
> evolve and stabilize quicker than if the only deployment was inside boost.

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.

- Volodya