Marking zapped bugs

[Matt McCutchen]

On Fri, 2011-09-02 at 13:54 -0700, Adam Williamson wrote:
> Hum, I didn't realize our resolutions were so customized, I thought they
> were the upstream ones; this is what I've been told when discussing
> custom resolutions in the past. It's certainly something you could
> propose as an enhancement by filing a bug against Bugzilla, then.

OK, I will do that and post the link here.  Any assessment of difficulty
provided by the Bugzilla team can inform a decision between 2a and 2b.

> > 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX
> > (semantically questionable on its face, but maybe reasonable in light of
> > the explanation on
> > https://bugzilla.redhat.com/page.cgi?id=fields.html#status ).
> 
> As noted at the top of that page, that is the policy for RHEL, not for
> Fedora. Fedora policy is
> https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It
> states only "The resolutions CANTFIX, WONTFIX, and WORKSFORME are for
> use by maintainers only, and are self-explanatory."

You are right.  But taking a step back, the project has the power to
change the policy to best meet its needs.  My point stands that the
resolution is little-used (less than 2% [1]), and its use for expired
bugs would harmonize with the current RHEL policy.  None of my 131 bugs
have been marked CANTFIX [2]; maintainers seem to find that the
better-known WONTFIX and NOTABUG cover the range of cases.

[1] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field=resolution&query_format=report-table&product=Fedora&format=table&action=wrap)
[2] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field=resolution&query_format=report-table&product=Fedora&emailreporter1=1&emailtype1=exact&email1=matt%40mattmccutchen.net&format=table&action=wrap

> > 3. Do not change the bug state, and have maintainers apply the same
> > conditions now used by the bug zapper on all of their searches.
> > Reducing mutable state is generally good in that it reduces the possible
> > ways for things to get out of whack.  But then it takes more work to see
> > whether a non-CLOSED bug is expired.
> >   3a. Like #3, but make it easier with a virtual EXPIRED resolution.
> > Probably an undesirable level of customization to Bugzilla.
> > 4. Add an "Expired" keyword or custom field, use it, and:
> >   4a. Continue to close the bugs WONTFIX.  Ugh, but I can use the
> > keyword/field in search and maybe even get it to show as a column on
> > search results.
> >   4b. Do not change the status, and have maintainers use the
> > keyword/field in their search.
> 
> I think if we're going to change this, the only sensible change is to
> use a different CLOSED resolution. All the others seem like hacks which
> are likely to cause more trouble/confusion than they resolve.

Fair assessment.

> We clearly
> want to bugs to be CLOSED, not open with a quasi-closed keyword or
> whiteboard field.

I'm not sure who "we" is, but I disagree.  The generally accepted
definition of CLOSED is that the resolution is final unless subsequent
events invalidate the original rationale.  (C.f. the RHEL policy: "The
bug is considered dead, the resolution is correct.")  All it takes for
an expired bug to be reopened is for someone to have enough interest to
retest it in a maintained Fedora version.  To claim that this meets the
definition of CLOSED is a big stretch.  I believe that "expired" should
properly be its own major state alongside "open" and "closed", but we
have alternatives that are less radical and still solve the immediate
problem with search.

-- 
Matt