On Wed, 2011-07-13 at 18:36 -0700, Adam Williamson wrote: > 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 fully agree. The net result is the same, I just don't think we should start tracking incomplete features as blocker bugs. > 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? Might be good to raise awareness, so they know we don't plan to automatically accept any features (delayed or approved) as blocker bugs. We do list a "goal" for the Alpha to "Test accepted features of Fedora 16". While that may on the face seem to indicate we should hold the release for all accepted features, I believe we intentionally listed this as a goal, and not a requirement. To fit this into our existing criteria vernacular, I would probably suggest that FESCO agrees to delay acceptance of the SysVinit->systemd feature until after Alpha. Acceptance would be revisited after Alpha and would pertain only to the proposed livecd scope. If the proposed changes are completed at that time, the feature would be accepted. Anyway, like you said, semantics. I'm just trying to make sure we're true to our criteria. Long story short, I agree it makes sense to keep this separate from the blocker process. Thanks, James
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
