Marking zapped bugs

Matt McCutchen matt at mattmccutchen.net
Fri Sep 2 18:01:09 UTC 2011


[Finally returning to this issue.  If your mail client doesn't thread
across this time span, see
https://lists.fedoraproject.org/pipermail/devel/2010-November/145105.html for the previous part of the thread.]

On Fri, 2010-11-05 at 12:19 -0700, Adam Williamson wrote: 
> On Thu, 2010-11-04 at 16:10 -0400, Matt McCutchen wrote:
> > On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
> > > The practical point is that F12
> > > is about to go EOL which means the bug must be closed...
> > 
> > Why?  Obviously it needs to be clear that nothing further should be
> > expected from the maintainer unless/until the version is bumped.  But
> > the project can choose to indicate that by closing the bugs as WONTFIX
> > or some other way, 
> 
> That's, um, exactly the process we're discussing here. We close all bugs
> for a given release when that release goes EOL. (I forget what
> resolution is used, it may well be WONTFIX).

The resolution is indeed WONTFIX.

> We send a warning note to
> all bugs that will be closed under this process, a short while before
> they're closed, so the reporters can check if they exist in a newer
> version and bump the report to that version to keep it open, if they
> like.

I'm well aware of the process.  The principle behind it is that
maintainers are not expected to act on bugs that have not been
reproduced in a currently maintained version of Fedora, and such bugs
should be marked so that users know not to expect any action.  I am not
disputing this.

However, the generally accepted definition of WONTFIX is that the bug
has at least some validity but the maintainer has decided not to address
it because the benefit fails to outweigh the cost (implementation and
maintenance effort + any negative side effects, to include going outside
the intended scope of the software).  Zapping bugs by marking them
WONTFIX is semantically incorrect and makes then hard to distinguish
from bugs that meet the accepted definition of WONTFIX; it has also
seemed on some occasions to lead maintainers to abuse NOTABUG to mean
WONTFIX.  Fedora is the only project I am aware of that does this.

I urge that bug zapping should be accomplished:

(1) With a different resolution, like Mozilla's EXPIRED (I can file the
bug against Red Hat Bugzilla), or

(2) Without mutating bugs in any way, but by publicizing that
non-FutureFeature bugs open against EOL Fedora versions are considered
expired and no action should be expected (GNOME seems to operate this
way informally).  Optionally, Bugzilla could be customized to return the
resolution of such bugs as EXPIRED to facilitate the exclusion of
expired bugs from counts/queries of "open" bugs as desired.

> If we don't auto-close bugs we wind up with a huge pile of ancient bugs
> which just gets in the way of people who want to come along and actually
> clean up the bug list for a package. It's harder to do that if you're
> looking at reports from the Stone Age.

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.

My broader point is that calling expired bugs closed is an
oversimplification, and possibly a disingenuously generous
interpretation of the situation.  I'd guess that among non-ABRT bugs,
well over 50% of expired bugs are still valid two Fedora versions later.
But regardless of the figure, I believe that each client querying
Bugzilla should be allowed to decide whether or not to include expired
bugs, as distinguished from true closed bugs, based on its own needs.
By stuffing expired bugs into the WONTFIX category, Fedora is depriving
them of that choice.

[I am not on the list; please keep me in replies.]

-- 
Matt




More information about the devel mailing list