Re: How does the Emacs bug tracker work?

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Thu, Jun 30, 2011 at 17:15, Chong Yidong <address@hidden> wrote:
 > 
 > > Similarly, we have lots of bugs tagged unreproducible and/or wontfix.
 > > We haven't been closing these, but if that bothers people, we could
 > > institute a policy of closing such bugs if there is no traffic after,
 > > say, a year.
 > 
 > Yes, please. I agreethat Wontfixes are perhaps valuables as
 > documentation, but closing them will not affect that.

Actually, it can.  The problem is that when you do a specific search
for the-bug-you-are-about-to-report, most trackers will apply the "not
closed" filter.  In that case there will be a strong tendency to
increase the number of dupes.

I think this is one case where users need one interface that normally
presents WontFix bugs to them, and maintainers need that interface
(for reporting and perhaps for trolling for WontFixes that they want
to fix :-) plus another one that tells them about only active bugs.

Does debbugs allow that distinction?

Or perhaps a DWIM interface that looks for WontFixes as well as open
bugs if the query contains sufficient specificity (the definition
would need to be tuned, though).

 > As for Unreproducibles, if no additional information has been
 > forthcoming in a year, its likely that noone is really interested in
 > pursuing the issue (or perhaps it was fixed somehow and nobody noticed
 > or reported it).

Agreed, these don't have the same problem.

 > > As for the rest of the old bugs, many are "long tail" issues that are
 > > difficult and/or time-consuming to debug and fix.
 > 
 > Yes. There are lots of bugs where there's a consensus that the problem
 > is real (though sometimes not what the OP reported), and then the
 > discussion sort of dwindles.

If they're really that hard, and there's a UI that shows WontFix to
users searching for a specific issue and hides them from developers,
you could Important/WontFix/Close the hardest ones.  Emacs has a very
disciplined group of core workers, and perhaps some would volunteer to
regularly troll for WontFix+Important or some such anomolous-looking
pattern, and reopen "interesting" ones.

Alternatively to all of the above, Roundup has a contributed script
that regularly (by default, each week) sends a bug summary to the
developers list.  I don't know how many Emacs developers would use
such a thing (it's a matter of taste, of course), but I know that
several people on the python-dev list use theirs -- it's visible in
their posts about "isn't it time to do something about this bug?" etc.

Note that some of the suggestions above are somewhat inconsistent with
each other and implementing all of them would result in excessive
complexity in the interface.