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
e) the new version is releases with a number like 1.31.1 or maybe even 28
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk