Re:[boost] Re: 1.32 release preparation
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
Robert Ramey wrote:
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.
As an observer, I'm fairly impressed with GCC's release methodology. http://gcc.gnu.org/develop.html A critical component is a schedule that includes several stages during which certain sorts of changes are unacceptable. There's still rush, but most of the rush for major features or other destabilizing elements happens long before the release comes around. Aaron W. LaFramboise
As an observer, I'm fairly impressed with GCC's release methodology. http://gcc.gnu.org/develop.html
A critical component is a schedule that includes several stages during which certain sorts of changes are unacceptable.
There's still rush, but most of the rush for major features or other destabilizing elements happens long before the release comes around.
I like the look of that, what we need more than anything else is clarity, otherwise the temptation is always there to slip in just one more feature... John.
On Sun, 27 Jun 2004 19:05:45 -0700, Robert Ramey wrote
Personally I think the concept of scheduling a release fundamentally flawed. I would suggest another idea.
Gee, I couldn't disagree more. In my mind, it is simply a time versus functionality tradeoff. Unlike typical project development since boost releases don't have a 'required' set functionality, we should be able to set a date and stick to it. Anything that doesn't make it in time is tossed out, period. I can even imagine taking a much harder line than is done currently by allowing the release manager to roll back any library that has seriously regressed or is causing problems. It will still take a month to run through all the various issues that come up, but it should be much more bounded than past releases.
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
The problem is that this may never happen without prodding for a release date.
...snip... Under this system, releases would occur more frequently - on the order of 6 weeks.
I would be fine with more frequent releases, but there is apparently a substantial amount of work to perform the release function (I don't have first hand experience, I'm just guessing this is true from the comments of folks that have). So the problem is we need more people to perform this task if we want to release more frequently. Of course, these are the same people that are often the same people that are writing and libraries -- so if we release more we might review less, etc. Of course the process can be more scripted, etc, but that takes someone to do it as well. Jeff
[Temporary] posted at http://tinyurl.com/2z5ak. Will be moved to the Boost website and linked from the main page later today. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
[Temporary] posted at http://tinyurl.com/2z5ak. Will be moved to the Boost website and linked from the main page later today.
FYI, this link on the front page isn't doing what it should: http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/status/1_32_rel... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"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
participants (4)
-
Aaron W. LaFramboise -
Aleksey Gurtovoy -
David Abrahams -
Jeff Garland -
John Maddock -
Robert Ramey