Alpha/Beta/GA blocker criteria?
awilliam at redhat.com
Sun Aug 9 07:23:20 UTC 2009
On Sat, 2009-08-08 at 13:52 -0500, Allen Kistler wrote:
> Are there any differences about what constitutes a blocker for the
> different cycles (e.g., alpha vs. beta)? One general basis would be
> different objectives for how much needs to work for the different
> pre-releases. I looked around, but I didn't find anything documented.
> Part of what started me looking is that anaconda appears to be unable to
> reuse existing ext filesystems when choosing custom layout on my test
> machines. (I like to reuse /boot for multi-booting.) How big a deal
> should that be for alpha, given that most early testing would involve
> blowing a drive away and starting from scratch?
> BZ 513104 for those interested.
There is a definition, but it's quite tough:
in practice, the net is cast somewhat wider at GA time, but we don't
have a hard definition.
We've been trying to work to a hard definition at least for Alpha:
considering bugs that significantly affect the critical path (see
https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal ) as
blockers. The definition of 'significantly affect' is basically
'severity high or urgent according to
but there are exceptions to this:
https://bugzilla.redhat.com/show_bug.cgi?id=515410 is one, it's
technically medium or even low severity, but practically it would cause
severe surprise to _everyone_ installing the Alpha, so we consider it a
blocker). To give a short definition without references: if it stops you
being able to install, get into a graphical desktop, or update the
system, it's a blocker bug.
We're trying to get to a decent solid public definition of blocker
criteria for each release stage, but in practice it's very hard to write
a policy that's both definitive yet sufficiently flexible to cover odd
cases. I'm not sure we'll ever get all the way there, but we'll do our
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
More information about the test