[boost] boost development process / scope

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-05-04 11:34:51

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.

Thanks,
                Stefan

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