On Wed, 2011-07-13 at 19:25 +0000, "Jóhann B. Guðmundsson" wrote: > On 07/13/2011 07:17 PM, James Laska wrote: > > Your ideas are consistent with how we've handled this before, I don't > > think I could have articulated nearly as well though:) My > > understanding is that FESCO is the right place to discuss whether a > > feature should block a release or not. > > They already did and decided that what's on core + base + base-x would > become alpha blockers which later got extended to included services we > ship on the live cd. I think we could still talk to them about tweaking that process, though. I could easily be misinterpreted here, so I'll try to be precise... We've set up this whole blocker bug process that works quite smoothly to achieve what it sets out to achieve: validate the quality of the release. We have the release criteria and the blocker bug SOP and the system of bugs and meetings to carry it all out. That's great. Ultimately what the process achieves is QA's sign-off on the release: if there are no blocker bugs we say 'this release meets Fedora's quality standards'. Now, it should always be true that if there are any blocker bugs, the release cannot go out. *But*, crucially, the converse is not true: it is not inevitably be the case that if there are _no_ blocker bugs, the release _must_ go out. All it means is that we - the QA group - sign off on the release and say as far as we're concerned, it's okay to go out. QA isn't the *only* group that signs off on releases. FESCo does too. As I see it, it'd be perfectly fine for FESCo to say 'well, even though it meets all the quality standards, we do not want to sign off on this release until Feature X is done'. As I see it, that's a _separate_ process from the blocker bug / release validation process. FESCo does not need to use the blocker bug process to manage its decision to sign off on the release, and I think it would actually be better if they didn't. I'm dancing on pin heads here to some extent - the practical result is going to be the same whether we use the blocker process to manage FESCo's decisions on the feature process or whether we decide to come up with a different process for that - but I think it helps to have processes that are clearly and strictly defined: I think if we use blocker bugs to manage some specific aspect of the feature process, it dilutes both processes. I think it'd actually work out better if there were a separate mechanism by which FESCo managed its choice of whether or not to sign off on the release due to issues in the feature process. Thoughts? Should I talk to FESCo about this? -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
