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?
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
