Re: [boost] 1.35 release approach (was [1.34.0] Deadline)

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-05-01 04:05:42

Jeff Garland wrote:
[...]
> Most of these libraries should be in 1.35, which will hopefully be
> released 'quickly'.  By quickly, I mean ~1.5 months...which means a
> beta release 1 month  after 1.34.  Yep, that's right, I think we need
> to set some very hard goals to re-energize the boost release process.
> After the '1.34 experience' I've become even more of an advocate a
> hard line release approach. That is, we should set the deadline and
> only accept code that can make it in the release timeframe -- if it's
> not ready then we take it out and let it slide to the next release.

I wholeheartedly agree! On the other hand for this to happen it is 
necessary to stop addition of new libraries now. Are there any approved 
libraries that aren't in CVS yet? If there are maybe they should be 
allowed a time slot for new additions, before going into a bug fix only 
mode.

> To minimize risk of delay and release the pent-up backlog of new
> libraries I believe we should hold all existing 1.34 libs constant
> and only add in new libraries that are basically ready to go now.
> I've actually done an 'alpha test' of this approach and it looks like
> this will work -- that is, most of the unreleased libraries can be
> build against a 1.34 core without dependencies on changes to existing
> libraries (there are a few minor exceptions).  Behind the scenes I've
> been encouraging developers of new libs to get their code into CVS so
> we will be ready to begin the nano-second after 1.34 ships.

Are you implying that you'd set aside all changes to existing libraries 
that are already in HEAD? Isn't this a bit tough on library authors that 
put in up to a year and a half to improve their libraries?

> Now, I realize that we have a plan to switch to subversion and have a
> new process that has been developed by Beman, etc. But it's my view
> that we should pursue a CVS based approach because it requires zero
> time to implement.  In the meantime the subversion conversion can
> proceed in parallel.  When everything is 100% ready to go we switch.
> My worry is that the conversion of regression testing, developers,
> and all other release process changes will wind up delaying 1.35 by
> several months.  Of course, if my pessimism is misplaced then we can
> switch to subversion for the 1.35 release.  Nothing will have been
> lost because we will have been testing new libs for 1.35 anyway.

Are there tools to keep Subversion and CVS repositories synchronized? If 
that's the case the adaptation of the infrastructure to Subversion could 
take place in a development branch while your plan is carried out.

> I believe this is urgent because a major backlog of unreleased Boost
> code has now developed.  The asio review was 1.5 years ago -- it's
> hard to fathom that it's not in a release yet.  It's simply not
> acceptable to wait even 3 months more to get asio and other 'new'
> libs into a boost release.  And besides, asio and the libs above are
> really just the short list: there's xpressive, GIL, bimap,
> accumulators, function types, and units that have been accepted now
> -- huge and important libraries.  And it's not stopping, there's a
> review backlog, a pile of SoC projects, etc.  We have to dramatically
> shorten the release cycle to get these libraries out into a release.

I believe there are to sides to this: one is to come out with 1.35 as 
fast as possible to make up for lost time, the other is to ensure that 
such delays do not happen again. In this respect I'm afraid that Beman's 
approach shares with the current one too much reliance on self 
discipline and team cohesion. Boost is too large and too intertwined to 
rely so much on self discipline and team cohesion simply is not there, 
apart possibly among a small number of veteran core developers. Witness 
for instance how many were taken by surprise by the switch to BBv2.

Cheers,
Nicola Musatti