On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
I think one of major goals is to be able to continue ongoing
development while at the _same time_ preparing a release.
To me number one problem is condensed in the statement "we are
going to release do not merge anything but regressions"
the process should sidestep this "lock-based" work-flow. Could
be useful to add something along these line to goals
section. (i.e. the speed and smoothness is a goal)
I've been staying out of this thread for the most part, but I
feel the need to comment on this part specifically. It's
quite common for most major projects to have a clear "we're
wrapping up a release" phase where work _is_ restricted to
bug fixing and stabilizing. They don't stop people from
working off in their development branches (no one could
effectively impose such restrictions even if they wanted to),
but they _do_ tighten down on what's allowed to be merged.
This is a forcing function that's just required. There's a lot
of issues that otherwise won't get sufficient attention.
If all it took was altruism then regressions would be fixed
immediately, bugs would always be fixed in highest priority
to lowest priority (assuming that could even be effectively
designed), etc.
Without the 'ok, guys, focus in this smaller more critical
subset of bugs' step, release branches would be created and
never polished (or focused down to the release manager to do
all the work if he's that skilled and/or generous of his time).
There's a phrase I'm trying to remember, but it's something to
the effect that 'hope isn't a recipe for success.'
Hoping that people fix regressions on release critical bugs
isn't sufficient. Incentive and steering is required. The
desire to ungate master branch merges is one approach that's
been shown to be successful.
I feel you've made a very important point here, and I've put up a
section in the wiki process talk page devoted to the subject.
http://wiki.dlang.org/Talk:Release_Process#The_Path_of_Least_Resistance:_Incentives_and_Barriers
Although debating ideas in here is welcome, please be sure to
post your ideas in the talk page, esp after there's a conclusion
made, otherwise your excellent idea may vanish into the Ether and
never become implemented as it should have been.
--rt
