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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
