Proposal: Target tracker bugs

James Laska jlaska at redhat.com
Wed Mar 24 18:58:47 UTC 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20100324/76959d73/attachment.bin 


More information about the test mailing list