"Jesús M. Navarro" <jesus.nava...@undominio.net> writes: > Why the package(s) got 400 bugs to start with? If the problem is there, > then it's there. If somebody opened the bug then there was a bug at > least on his opinion which nobody challenged. If there was a bug, then > it need to be supposed that it will be there till there exists clear > indication on the contrary. Anything else is awful practice.
I would argue that by the time the package reaches several thousand open bugs, all of which are some random mix of upstream, fixed, unreproducible, packaging, and incomplete reports, the BTS has become essentially unusable for everyone. The maintainers rarely have time to go back and look at those thousands of bugs in any meaningful way, and users are not going to be able to reasonably search through that many bugs to see if any of them are the problem that they're running into. At that point, the BTS is about as useful as a mailing list archive and the only chance that anything in there is going to be helpful is if Google happens to index it. In my personal experience, generally at that point the mailing list archive of wherever the bugs were originally sent is actually *more* useful since it's better-indexed. I think we have a significant failure mode here with packages that get large numbers of bugs. The BTS becomes pretty much unusable without very active triaging for those packages. And this is not a Debian-specific problem; for example, it's essentially impossible to extract any useful information from the Ubuntu nvidia-graphics-drivers bug page, and it only has 350 bugs. (Launchpad is, in my experience, worse than the Debian BTS at handling large bug volumes and becomes unusable faster.) There are a lot of things that have been said on this thread that I completely agree with for the average Debian package that gets a handful of bugs a month and doesn't have more than 50-100 bugs open at a time. I think most of the people commenting here have dealt primarily with those sorts of packages, and that's the experience in which the comments are grounded. Packages with thousands of bugs are another world, and while I agree with the drawbacks of aggressive bug triaging, I think aggressive bug triaging is still a better approach than letting the BTS page become a junk pile of abandoned reports no one is ever going to look at again. Obviously, the ideal is to have teams that scale with the incoming bug count for the package, who will stay on top of all those bugs and categorize them appropriately and ping unreproducible bugs, forward upstream bugs, and do all the great things that make the world a better place. But in the world in which we live, that manpower simply doesn't exist. If wishes were horses, beggars would ride. We have to apply strategies that are realistic given the manpower that we actually have, not the manpower that we wish we had. -- 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/87vd1rt4i0....@windlord.stanford.edu
