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