Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-09-07 15:52:47


Rene Rivera wrote:

> * Being a release manager is a lot of work because of the size and
> scope of Boost.
>
...

> For 1.35 the release manager is going to face not just fine tuning the
> process, but overhauling it. The repository changed, the process is
> changing, and the tools are changing. Additionally, from my POV, the
> discussions about the new release process don't seem to be progressing
> at a quick enough pace. This made me realize it would be unrealistic
> for me to devote the need time that being a release manager would
> require. So the simple idea is to have a "Release Team" instead of a
> "Release Manager" to distribute the work and hopefully smooth out the
> attention a release gets. The dynamic would be:

The short form of the above is - Its a bigger job than it used to be - we
need more people.

In my opinion this is 180 degrees in the wrong direction. It will make
things worse rather than better.

The right way to think about this is: Its a bigger job than it used to be -
Divide into smaller jobs. This means just adding one tested library at a
time.

So the next release should be the 1.34.1 release with just the stuff that's
has been proved to be ready now. As far as I can see, the only
library that meets this criteria is Joaquin's Multi-Index which has been
tested against 1.34.1 and is currently available as a separate upgrade
to 1.34.1.

If you can find Three people who want to be release manager, then
line 'em up and give them 1.34.2, 1.34.3 and 1.34.4.

Now someone is going to say - that's too hard - You're tripling the work !!!

Ahhhh - and why is that? That's because the build/release system is waaaaay
to fragil. I'm still having problems with in spite of spending significant
amount
of time to make this thing work. Boost Build has to be packaged as a
separately
testable component that can be subjected to the same kind of offline testing
that
the libraries are subjected to. Basically, the whole release process is
serving
as a debugging procedure for Boost Build. This make creating a release
hard.

Soooooo, to summarize,

a) Move to incremental releases

b) Formalize the developement of Boost Build to the standards demanded of
other
boost components.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk