Next focus: PROCESS
deadalnix
deadalnix at gmail.com
Sat Dec 15 12:07:31 PST 2012
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.
Very good point. The final sprint is a good practice to adopt.
More information about the Digitalmars-d
mailing list