Proposal: Target tracker bugs

Jesse Keating jkeating at redhat.com
Thu Mar 25 02:26:16 UTC 2010


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
-------------- 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/2f82a780/attachment.bin 


More information about the test mailing list