Adrian Bunk <> writes:

> "no one is ever going to look at the bug again" is actually impossible
> to prove for a project like Debian - some new Debian developer or even
> some new upstream developer might actually look at it tomorrow or in a
> few years.

Yeah, I know, and this is a valid point, and is the reason why we all keep
some bugs around.  And there's some merit to doing that.  But I think we
generally keep too many bugs around.

We've had this conversation a few times before on debian-devel, without
reaching much in the way of an actionable conclusion.  But it's very hard
to do bug triage for popular, large software packages (the kernel, the X
stack, GNOME, that sort of thing).  Even if you filter out unactionable
bugs, there are so many bugs that look reasonable in isolation, but the
math indicates that most of them will simply never be addressed.

The other angle on this that people underestimate is that most bug reports
have a useful lifetime.  I've certainly done my share of resolving really
old bug reports, and it's quite satisfying when it happens.  But it's also
very common to look at old bugs and realize that the world has changed and
the software has changed to the point where the bug report doesn't really
apply.  Or, even harder to detect, the original bug reporter doesn't have
the same problem any more or isn't even using the software, and no one
else has cared (which is impossible to measure, sadly).  Or the problem
has subsequently been reported in some fresher bug that people are
actively working on.

This is why, in a work environment, it's usually someone's job (and has
often been my job) to do backlog grooming, close out bugs that have become
irrelevant, close out bugs whose priority is so low that no one should be
working on them, and try to keep the backlog actionable.

Now, the sort of aggressive grooming you do in a job isn't appropriate for
a volunteer activity without some changes.  For one, there's no agreed-on
priority across all contributors; one person's low-priority bug may be
someone else's starter project.  So it's much less useful to close out
bugs purely on a priority basis.  And, as you say, there's no way to know
for certain that you won't get a sudden influx of volunteer activity
(although I think we have to be realistic about how likely that is).

But still, despite all of those caveats, I do think there are a few things
that are fairly clear-cut.  If the package has 3,000 open bugs, just close
out the unactionable reports in some polite and constructive way.  At that
point, there are so many actionable bugs ahead in the queue that those
reports are adding clutter and making it harder for people to get a handle
on the bugs that can be directly addressed by the package maintainers.

> So allowing users to report bugs against stable does often already
> create unrealistic expectations like "someone will look at the bug" or
> even "the bug will be fixed in stable".

Yeah, bug reports against stable are another very tricky area in Debian.
There are packages where they will be addressed; for example, I have a lot
of packages with <10 (and often 0) bug reports, and I will look at and try
to resolve bugs against stable on those packages.  But for something like
GNOME, it's unrealistic to expect much resolution of bugs only in stable
unless they're particularly severe.

Russ Allbery (               <>

Reply via email to