"Robert Ramey" <ramey@rrsd.com> writes:
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.
We have a book deadline and we need to have a CD go out with the book, and the CD needs to contain a new boost release. So schedules are, at least occasionally, a fact of life.
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.
What if things don't ever look "pretty good" without intervention?
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
How is that a change from what we're doing?
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.
Experience shows that merging in the other direction tends to be safer and more productive.
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.
This reminds me of recent suggestions I've heard that new C++ standards could be released on a 6-month timetable. I think you'd feel differently if you had ever managed a release.
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.
You have a point. I have some trouble with details of your suggestion, but I think it has merits, too. Also, without a release deadline, would accepted libraries *ever* get checked in? ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com