Re: What bug reports are for
Hi, Russ:
En fecha Martes, 1 de Marzo de 2011, Russ Allbery escribió:
> "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.
No, I don't think it is. #3 *is* a bug since the moment somebody has referred
it as such.
> 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).
That maybe the case, but you won't know till you take the time to research it.
All you know prior to that is that it is there, on the bug tracking system,
therefore it is a bug.
> 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.
Completly agreed, but absolutly unrelated. That it is no worth paying
attention to it (even if that's truly the case) makes it any less of a bug.
> 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.
I think I'll go here into troubled waters but It's my opinion (as somebody
that has worked implementing and policying issue tracking systems, so I think
it's an informed opinion, but just an opinion nevertheless) that there's no
thing such too long a bug list.
What it usually happens (at least in my experience) is that too long a bug
list hurts the ego of the one that think of himself as being responsible for
that so we, being humans the way we are, feel a strong inclination to
"resolve" it by whatever means we find and being an easy scape path sweeping
them under the carpet, that's what we'll do. It takes a strong and well-
ballanced ego just to recognize that, well, there's simply not enough man-
power to deal with it, so focus must be centered on what brings better cost-
benefit ratio (bugs #1 and #2) and let #3 accumulate even if that makes for an
"ugly" bug list for the 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.
Which, again, is a perfectly acceptable outcome with a perfectly acceptable
remediation (me, the user, stepping forward to offer my help). Sweeping bugs
under the carpet is not a valid remediation even as the long bug list is
heartly painful for its maintainer.
Cheers.
Reply to: