Alpha/Beta/GA blocker criteria?

[Adam Williamson]

On Mon, 2009-08-10 at 01:06 -0500, Allen Kistler wrote:

> So there's kind of two topics here.
> 
> First is release criteria, which ideally would be tied to development 
> and the freezes.  Something like:
> Alpha: no core high/urgent, no critical path or Gnome urgent.
> Beta: no core medium/high/urgent, no critical path high/urgent, no Gnome 
> urgent.
> GA: no core medium/high/urgent, no cp medium/high/urgent, no Gnome 
> high/urgent.
> Bugs could always get fixed earlier, of course.

core is part of the critical path, so you can simplify that tree. We're
still not entirely sure how practical it will be to link severity to
release-criticality, though so far it maps quite well; there _are_ cases
where a lower severity bug can still be release critical, and vice
versa. Though they ought to be rare. Really, anything that's 'urgent' as
properly defined is probably a blocker for at least the final release,
and I do review the full list of urgent bugs during blocker meetings if
there's time.

> That's not anywhere close to a formal proposal.  I'm not trying to start 
> a fire.  I'm just wondering aloud how to make the release criteria 
> complementary to the freezes.  Plus I'd let the paid test lead try to 
> sell it to the steering committee, anyway.
> 
> Second is 513104.  On the day of the alpha go/no-go meeting, I doubt it 
> would be popular to add a bug to the alpha blocker.  So I'll just add it 
> to the beta blocker.

It's not a question of whether it's popular, it's a question of whether
it's right :). However, since the purpose of the Alpha is primarily
testing - we envisage it being installed on systems (real or virtual)
which are essentially disposable - this kind of bug usually doesn't get
over the blocker threshold. There are obviously ways to get the install
done on a system which runs into this bug (get rid of the offending
partition). The fact that it might stop certain install test cases from
being testable is regrettable, but doesn't mean the Alpha should be
blocked, because we can always test those from a Rawhide tree once the
bug's fixed. Please do feel free to bring it up at the go/no-go meeting,
though. We always want to err on the side of 'wasting' time by
considering more bugs, versus missing one we really should have caught.

> Not just reusing ext2/ext3 filesystems (like /boot), but test cases like 
> upgrading ext2/ext3 to ext4 should also fail, since they're not detected 
> in the first place.  Or is it just me?

I'm not sure if the same detection code is used, perhaps an anaconda dev
can answer.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net