Marking zapped bugs

[Matt McCutchen]

On Fri, 2011-09-02 at 12:29 -0700, Adam Williamson wrote:
> On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote:
> 
> > What you're really saying is that most maintainers want to work from a
> > list of unexpired bugs.  But there are ways to achieve that other than
> > marking all the expired bugs WONTFIX.  Maintainers can always filter on
> > the currently maintained Fedora versions, but it becomes tedious to
> > configure that, which is where a virtual EXPIRED resolution exposed by
> > Bugzilla would come in handy.
> 
> Mostly your proposal makes sense,

Thanks for the response.

> but we're trying very hard to stick to
> upstream Bugzilla since 3.x, as heavy customization of 2.x caused more
> problems than it solved. So we're reluctant to add resolutions and
> statuses that don't exist upstream - even if Mozilla have hacked up
> their own copy of their own upstream bug reporting system to add
> resolutions...

I don't buy that: Red Hat Bugzilla currently has 4 upstream resolutions
to 7 custom ones.  Are all the custom resolutions actively being phased
out?  Otherwise, can you give some examples to illustrate the marginal
harm likely to occur if an 8th custom resolution is added?

I'm disappointed that you don't appear to buy that this is important
enough to merit discussion of alternatives, rather than just raising a
problem with one of the ones I mentioned.  The status quo may be fine
for a maintainer or triager going down a work list, but when I as a user
review old bugs related to a topic (perhaps to see whether a new bug is
merited or I should join an old one), "expired" is equivalent to NEW
rather than WONTFIX as far as I'm concerned, and it's annoying to have
to open each WONTFIX bug to determine which kind it is.

We have a number of options here which vary in implementation effort and
how much burden they impose on user and/or maintainer to get what they
want from an inadequate representation:

1. Status quo: hard to distinguish expired from WONTFIX.
2a. Add EXPIRED resolution and use it.
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 ).
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.

No one should object to 4a as a change (though I recognize I am still
asking someone to do work, especially if existing bugs are to be
reclassified).  We could start with that and at least stop losing the
data in the next bug zapping cycle.

I would appreciate your honest consideration (Adam and any other
relevant parties).

-- 
Matt