Exit Criteria to Production and Release Blocker Nominations

[Null Ack]

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.

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.

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

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.