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

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-01 10:04:56

Nicola Musatti wrote:
> 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.

property tree, bimap, accumulators at least.  But yes, we would need to 
specify a cutoff for addition to make the schedule.  However, with more 
frequent releases it's not as big a deal if something slips.

>> 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?

Yep, but I suspect many of the really critical fixes got moved into 1.34.  If 
there's someone with a really important exception it could be discussed, but 
it would have to be really good.

>> 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.

Don't know, but I'm sure the infrastructure development can be done in 
parallel with just a little thought.

>> 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. 

Actually, I think Beman's new approach is much closer in philosophy to what 
I'm suggesting.  As I recall in provides for a small window to fix regressions 
after which breaking changes will be reverted.  It's ultimate goal is to keep 
the HEAD much closer to release at all times.  Still, it is untested so we 
don't know how it will really work yet.

> 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. 

Actually I think the main thing is that Boost is getting large enough now that 
there's almost always something being changed.

> Witness for instance how many were taken by surprise by the switch to BBv2.

I don't want to dwell on BBv2, but after doing several similar conversions on 
large projects I was afraid it would be much harder than expected -- it's 
extremely hard to even make a list of all the things to do let alone what will 
go wrong.  And when something goes wrong progress bogs down. I fear the same 
thing with subversion conversion.  On it's face it should be easy, but there's 
alot of people, tools, and small non-obvious dependencies on CVS.  I haven't 
even seen a list of all the scripts, web pages, processes, etc that need to 
changed before the changeover can be completed-- so I'm afraid we don't fully 
understand the impacts.

Jeff