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

From: David Abrahams (dave_at_[hidden])
Date: 2007-05-02 06:18:23

on Mon Apr 30 2007, Jeff Garland <jeff-AT-crystalclearsoftware.com> wrote:

> Thomas Witt wrote:
>> In article <624789.81580.qm_at_[hidden]> Cromwell Enage
>> <sponage_at_[hidden]> wrote:
>> 
>>> A few somewhat-recently accepted libraries (e.g. ASIO,
>>> Fusion, Interprocess, MPI, PropertyTree) are available
>>> in both the beta distribution and via CVS but are not
>>> advertised in either libs/libraries.htm or
>>> doc/html/index.html; will their presence at least be
>>> announced in the news section of the home page during
>>> the official release?
>> 
>> As of now there is no such plan. They are not part of the official release
>> and as such are not mentioned in the docs.
>> 
>
> To clarify, none of the listed libraries are in the beta distribution I have. 
>   And property tree isn't in CVS yet AFAICS.
>
> 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. 

Agreed.

> 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 agree in principle that it's a good approach.  However:

  1. letting code slip in after deadlines is not what held up 1.34.

  2. You have to be careful that taking code out doesn't break more
     stuff than it fixes.

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

That's a fantastic idea.

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

I think I disagree, though not strongly.

> In the meantime the subversion conversion can proceed in parallel.

No it can't.  The way it works is: 

  1. freeze CVS
  2. convert it to subversion.

You can't (reasonably) convert CVS to subversion, work in the
subversion repo, and then somehow merge an updated CVS back into SVN.
Or did you have something else in mind?

The subversion repository is ready to go now.

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

I agree that's a potential danger.  We should look carefully at what's
involved here.

1. Regression testing doesn't use (actually, doesn't require) CVS.
   Those optionally using CVS now can just as easily "optionally use"
   SVN.

2. Developers.  What?  Setting up passwords and accounts?

3. All other release process changes.  What are they?

So far I don't see any serious issues.  If you can be more specific
I'm open to chaning my mind.

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

I don't understand that last sentence.

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

Agree.

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

Agree.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com