Proposal: Target tracker bugs

James Laska jlaska at redhat.com
Wed Mar 24 15:50:38 UTC 2010


On Wed, 2010-03-24 at 08:37 -0700, Jesse Keating wrote:
> On Wed, 2010-03-24 at 11:30 -0400, James Laska wrote:
> > On Tue, 2010-03-23 at 17:21 -0700, Adam Williamson wrote:
> > > Hi, everyone. At a recent Bugzappers weekly meeting, we discussed the
> > > FXXTarget tracker bugs - F12Target, F13Target etc. We agreed they were
> > > not serving much of a purpose recently, as developers do not appear to
> > > devote any extra effort to these bugs as compared to others. We also
> > > noted that the Severity field serves much of the function of these
> > > trackers, now we are using it again.
> > > 
> > > At the meeting we agreed to draft a proposal to discontinue the use of
> > > these trackers. However, at the last blocker bug review meeting, Jesse
> > > Keating suggested an alternative use for them. We often find ourselves
> > > in the position, in the period shortly before a release is made, of
> > > saying "well, this bug isn't a release blocker, but if the developer
> > > comes up with a fix, we'll accept it through the freeze". Jesse proposed
> > > we could use the Target trackers to track this kind of bug - one for
> > > which we would accept a fix into an impending release.
> > > 
> > > Does anyone have a clear preference for one of these paths or the other?
> > 
> > As we rely more and more on the release criteria and addressing bugs
> > that are on the blocker list, I'm seeing a hesitation to fix any other
> > bugs in Branched.  In some sense this is a good thing, less change
> > generally means more stability.
> > 
> > However, for issues that we've previously identified as 'nice to have'
> > issues where the patch (or suggested fix) has limited scope, I don't
> > want to prevent informed developers from addressing these issues in the
> > Branched release.  Using the Target bugs seems like a fine way to denote
> > 'nice to have' and acceptable for including in the Branched release.
> > 
> > Thanks,
> > James
> > 
> > 
> 
> My worry is the size of the target trackers, and our ability to
> appropriately manage them.  We're already running into this with the
> Alpha/Beta blocker list, maintainers don't know for sure if the bug has
> been "accepted" as a blocker or not.  Since anybody can make the bug
> blocking relationship, there is that period of uncertainty and doubt.

True.  I was thinking of the Target list as something we wouldn't manage
as we managed the Blocker lists now.  I was thinking of later proposing
that we only accept Blocker (must have) and Target (nice to have) fixes
for crit-path components.  

Then the existing distinction between the two would still apply.  We
would hold the release until all Blockers are resolved, but we wouldn't
for Targets.

> As much as I'd hate to move to using flags of some kind, I really do
> think there is room to distinguish between a /proposed/ blocker or
> target bug and an /accepted/ blocker or target bug.  Either a flag that
> goes from ? to + or a keyword added by one of us during our blocker
> review meetings, it should be really lightweight, no where close to the
> 3 ack system RHT uses for RHEL stuff.
> 
> ... discuss?

I don't have objections to using flags.  To me, it just feels like a
different implementation meant to address the same issue?  But as you
noted above, flags do offer a bit more in terms of information about a
request.

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/9f4498f6/attachment.bin 


More information about the test mailing list