Alpha/Beta/GA blocker criteria?

Adam Williamson awilliam at
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 ) as
blockers. The definition of 'significantly affect' is basically
'severity high or urgent according to ,
but there are exceptions to this: 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

Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org

More information about the test mailing list