Re:[boost] Re: 1.32 release preparation

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-06-27 21:05:45

Dave Abrahams wrote:

>I'd like to know the reasons for "all the sudden rush".  We did
>announce a schedule long ago, and it has already been delayed by three
>weeks.  I'm not asking in order to point fingers; I just want to know
>how to avoid the "sudden rush" next time.

Here is the current scenario. 

a) The announcement gets posted - release 1.32 scheduled for date x.
b) Each developer decides - uh oh I better get in my changes before date x.
c) Of course these changes take longer
d) and break some other things
e) which takes longer still

Personally I think the concept of scheduling a release fundamentally flawed.
I would suggest another idea.

a) the release manager or the core influential developers keep an eye on the
current state of the CVS tree and tests.  
b) When things look "pretty good", branch for release without warning.  None
of this loading my latest feature in to make the schedule.
c) the Main tree goes on as usual
d) pending issues in the release branch are addressed by nagging the person
responsible.
e) the new version is releases with a number like 1.31.1 or maybe even 28
July 2004.
f) any changes between branch and release should be just bug fixes which can
then be merged back into the development tree.

Under this system, releases would occur more frequently - on the order of 6
weeks.  If you're ready to check in your latest feature and the new release
branch catches you with your pants down - well too bad. But it's no big deal
because the next release will be in 6? weeks anyhow which is close to what
its going to take to shake out the repercussions of your check in anyway.

I realize that this is not the most orthodox way of doing things.  But I
think it's really hard to get such a large number of people working
independently on exactly the same schedule.

>How come we have so many
>accepted libraries that have not even been put in the CVS?

Almost all libraries are accepted subject to some changes being made.  Many
such changes seem simple but end up rippling through the whole library. This
takes time.

Once a library is accepted, then one can get serious about making it pass
with a larger number of compilers.  This also takes time - a lot of time

These changes end up having a ripple effect and can result it changes like
moving things in namespaces and subdirectories.  While this is going on, the
system is broken and really not suitable to be subject to the daily testing
routine.  So it seems attractive to deal with all this stuff before one does
the initial check in to CVS.  This way one can start with a relatively clean
start.

Robert Ramey