On Wed, 2011-10-05 at 16:02 -0400, Konrad Rzeszutek Wilk wrote: > > What's necessary to make it a release blocker is not so much 'it'd be > > nice if it worked' arguments - I think in general everyone agrees it'd > > be nice if it worked :) - but more 'it would be terrible to release > > without it working, because' arguments. That's the level of impact we > > need for release criteria, because something being in the release > > criteria means that if it's not working, we don't ship. Which is a > > pretty high bar to get over. > > There are kernel developers who are willing to write and test code. > There is also a community of folks who are willing to test install/provide > patches for grub/grub2/grubby/etc. > > However, I am ignorant in the ways of making a release go out the door > - so I am not seeing the full picture. What are the missing pieces? It's not so much a question of 'do we have the resources in place to probably make sure it works at release time' but 'is it a terrible disaster if we make a release in which it's broken'. That's what the release validation process is meant to ensure, and _only_ that. It's not like, if we don't make it a release blocker, it means no-one will care about Xen and it will always be broken. I'm still madly catching up with stuff, but for me the only consideration so far which falls into this category is the EC2 one, but that is a *big* consideration. It's pretty close to being enough to make me vote to have it as a criterion. It would certainly be unfortunate to ship a release you couldn't install as an EC2 guest. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
