Exit Criteria to Production and Release Blocker Nominations

[Scott Kitterman]

On Thu, 12 Mar 2009 16:21:47 +1100 Null Ack <nullack at gmail.com> wrote:
>Scott,
>
>> This is a bit different than typical commercial efforts where after a point you
>> essentially stop work on anything that's not a blocker.  So while it seems
>> worse, I'm not so sure how bad it really is in comparison.
>
>That's a key point I'm making - the definition of what is a blocker on
>Ubuntu is of a lower standard than projects I'm involved in where I
>get paid. Simply, the users wouldnt put up with it.

If you set the bar to high, we'd never release.  Adding to the list of must fix stuff without taking something else off the list doesn't help get more work done.

>The Ubuntu policy is not driven to a quality user experience - in
>practice its driven exclusively by major bugs. Although what some
>might consider to be major bugs have in the past also be declined
>release blocker status due to what I suspect to be an absence of
>capability to fix it before release.

I think you're making a distinction without a difference.

>> So far you've failed to offer a better alternative, so I have no idea what
>> you are talking about.  Exhorting people to fix more bugs is not a solution.
>
>I was suggesting a compromise of an additional release nomination flag
>and release process that would be designed to be higher priority for
>say paid Canonical developers to fix before much work starts on the
>next release. Obviously this depends on specifics like the time to
>fix, impact to regressions as you mention and so forth. It would be a
>mechanism to get fixes in much before the next release and before
>developer attention is distracted to new things in the next release. I
>realise this may or may not happen now under stable release updates,
>but an additional flag would more formalise the process and provide
>tracking of how progress is going.

Adding a flag does nothing for getting more fixing done.

>Some of this stuff could be sorted out before it even got to a testing
>stage by having better release entry criteria into the dev repos but
>thats another subject from a previous email I sent the list.

Right.  Since the bulk of our archive is automatically sync'ed from Debian this is another massive piece of work that there is no one to do.

Unless you can find more developers, then your proposals need to reduce existing workload if you want new work done.

Scott K