On Wed, 2010-03-24 at 14:58 -0400, James Laska wrote: > On Wed, 2010-03-24 at 11:21 -0700, Adam Williamson wrote: > > On Wed, 2010-03-24 at 10:51 -0700, Jesse Keating wrote: > > > > > > In the interest of simplicity and not having to revise a bunch of > > > > pages :), how about we just add a comment to any bug that's accepted > > > > as > > > > a blocker during a review meeting? > > > > > > > > We already add a comment to any bug that's *rejected* as a blocker to > > > > explain why we're rejecting it, so this would match that quite nicely. > > > > > That works somewhat but is not queryable. > > > > True. I'm not really that opposed to using a flag, it's just it'd > > involve quite a lot of re-education (just when we're getting people used > > to using the blocker bugs) and editing documentation. I'm not sure it's > > a significant enough problem to make the disruptive fix an overall > > benefit... > > If we want policy around the bugs permitted for critpath packages in > Branched or existing releases, I believe we'll need to use something > more query-able like flags (as Jesse suggests). But perhaps that's a > future discussion. > > Lemm ask, how are we using the Target and Blocker keywords now? I think > they offer 2 methods ... > > 1. for testers to can escalate failures in critpath packages they > believe affect the release criteria (Blocker) > 2. for critpath packagers/developers to request including fixes not > considered release Blockers > > Is this right? Not really. 1 is right, however there is little to no visibility that once 1 has been done, the "powers that be" have accepted the escalation. Also it's not limited to critpath packages. 2 isn't even close. Historically we've used Target thusly: When issues are proposed as release blocking, and "the powers that be" decide that we wouldn't in fact delay the release for those issues, we often put them on Target, which gives developers an easy way to see issues which are "important" to work on, but not "important enough" to block the release. But really there is little interaction between the Target tracker and the "powers that be" beyond the initial dropping. Target has been more for the maintainers' tracking than anybody else. Currently releng does not use any criteria of blocker or not to gate movement between updates-testing and stable. We have been unwilling to go down that path where maintainers have to monkey with the system and file unnecessary bugs or lie about the bugs they are fixing in order to have an 'approved' change set. Instead we trust our maintainers to do the right thing, and help verify that with bodhi karma. So, I don't want to see the flags and such used as ways of preventing changes, rather I want the flags and such to be used as ways of communicating clearly to maintainers issues which we will in fact delay the release for, which are the highest priority issues for them (or others) to work on. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
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
