Release-critical bug process?

[Christopher Beland]

I updated

https://fedoraproject.org/wiki/QA/ReleaseCriteria

to summarize the comments on the mailing list about how the process
currently works, given that it has been reaffirmed as how the process
*should* work.  (Corrections and clarifications welcome; feel free to
change the wiki directly.)

On Wed, 2009-02-11 at 14:43 -0800, Adam Williamson wrote:
> a) We should see the point of alpha releases as being basically to
> provide an updated installer tree. Only bugs that break the installer or
> prevent you being able to get logged in and run 'yum' should be
> nominated for the Alpha release trackers.

The QA/ReleaseCriteria page makes a distinction between test releases
and final releases, but not between alpha and beta and preview releases.
This page should be definitely be rewritten to reflect the current
practice.  Perhaps it would be useful to split it into Alpha, Beta,
Preview, and Final sections, instead of just relying on MUST vs. SHOULD.

> b) We all more or less agreed that the process should make it quite easy
> to nominate a bug to 'block' a release, and bugzappers will probably do
> a lot of that...

Perhaps it would be advantageous for BugZappers to have a goal of
triaging all bugs marked "urgent" in Bugzilla relatively quickly.  This
is the easiest way for bug reporters to flag possible blockers,
especially the inexperienced and those who only have Bugzilla accounts.
(It also provides quicker help to the people who are most upset about
the bug they have reported.)  There are currently 116 "urgent" bugs in
the "NEW" state, though only 11 are in Rawhide.

-B.