"Jesús M. Navarro" <jesus.nava...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjv7lpey....@windlord.stanford.edu
