Next focus: PROCESS

[Brad Roberts]

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.