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
