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