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