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