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