Re: What bug reports are for
"Jesús M. Navarro" <jesus.navarro@undominio.net> writes:
> En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió:
>> Now, maintainers receive a lot of bug reports, and have limited time to
>> spare on Debian. Given the choice between:
>> 1. packaging a new upstream release that fixes a lot of bugs;
>> 2. fixing a nicely reported bug with a reproducible and
>> well-identified cause;
>> 3. investigating a dubious bug report that seems to be triggered by
>> a broken user configuration;
>> only masochistic maintainers will spend time on #3 when they can help a
>> lot more users on #1 and #2. It’s not that it’s easier (I remember
>> spending entire days on single bugs), but it’s more useful.
> True, and I don't think anybody would expect any more.
> But #3. is still a bug and unless it's been at least tried to be
> reproduced is no good behaviour to close it just "because I've not the
> time and I prefer focusing on #1 and #2".
> I'm not telling this is the case for this bug since I really don't know
> it but as a general matter, but *if* that were the case, no, I don't
> think sweeping bugs under the carpet is a proper policy.
Well, maybe #3 is still a bug. That's the problem, right? We don't know
that.
The trouble with things that fall into category #3, apart from just taking
way more time to investigate, is that they may or may not actually be
bugs. Frequently once one investigates, one finds that it's not a bug in
any useful fashion (it's already fixed, it's caused by something on the
user side against which it's not reasonable for the package to take
precautions, the user's system was in some broken state, or no one can
reproduce the problem and the user isn't replying). And it can take a lot
of time to get to that point of realizing that something in #3 isn't an
actionable bug.
Meanwhile, #1 and #2 are much more efficient in terms of maintainer time
to fixed bug ratio.
The #3 reports aren't *useless* in aggregate (although individual cases of
#3 often are individually useless), but they are almost always less useful
in improving the package quality than #1 and #2. This means that they're
probably still worth spending time on if all #1 and #2 tasks are complete,
but if there are #1 and #2 tasks pending, #3 is probably not worth paying
attention to.
Now, for most packages, #1 and #2 bugs tend to get resolved relatively
quickly, or at least end up in some stable state (such as understanding a
#2 bug but realizing it's going to take a ton of work to fix), so
maintainers get to the #3 bugs. But what happens with a package that gets
so many bugs that maintainers can't get to all the #1 and #2 bugs? Are #3
bugs actually even useful to track at that point?
I think one of the arguments being made in recent discussions is that if
one is already overwhelmed with bugs of type #1 and #2, even tracking bugs
of type #3 may be more trouble than it's worth. The additional overhead
of having the appear in bug listings and the additional users who file
duplicate bugs because the bug list is so long they fail to check for
duplicates at all may cause more aggregate work than the #3 bugs provide
in utility for that package. And we have a fair number of packages in
Debian that get enough bug reports on an ongoing basis, relative to the
number of people working on them, that the chances of us ever cleaning out
all the #1 and #2 bugs and having it be worth our time to work on #3 bugs
is essentially zero.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: