Next focus: PROCESS

[Dmitry Olshansky]

12/15/2012 11:03 PM, 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.

I understand the desire of focusing people attention on a priority but 
there is no denying the fact that only a small subset of folks that is 
able to (say) fix a regression in the compiler.

What I'm trying to avoid here is a situation where the compiler team 
fights with last regressions but the phobos development is frozen. Or 
the other way around. There could be a couple of these ping-pongs during 
the process. And that's what I think we had and is suboptimal.

It's part of process to have a frozen view t in a form of staging branch 
but keep the master branch going. Otherwise it's just more branches (and 
pain) for no particular purpose.

> 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).
>

In the grander scale it boils down to managing who does what. Basically 
there should be a release check-list that everybody knows about: a list 
of issues and takers that currently work on them (Bugzilla provides that 
and should be more heavily used). If it's more or less covered (or 
nobody else could do it) the others may go on with the development on 
master.

The main problem I see with "everybody focus on these" is that I expect 
the number of contributors to grow but their area of expertise to get be 
more and more specialized (in general). Thus IMHO it won't scale.

> 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.
>
Yes. The focus of never stopping the development is to encourage new 
contributors by providing shorter feedback cycle.

-- 
Dmitry Olshansky