Frank Küster <[EMAIL PROTECTED]> writes: > It would be good if there was a way to find out "problematic" packages, > by extracting information about
> - how many bugs does a package have > - how many of them don't have a single response > - how many have not been dealt with for n months (or days/weeks for RC > bugs) > - how many packages depend on the package > and try to create some rating or ordering. One could then not only > identify packages that could use some work, but also for which of them > it's most useful. <http://haydn.debian.org/~thuriaux-guest/qa/global.html> Was posted to debian-devel a few days ago. :) > Another good thing would be an effort to go through important packages' > ancient bugs and clear them up. E.g. all those, mostly years-old dpkg > bugs that report a segfault. Either something should be done about > them, or they should be closed. Amen to this. As soon as I finish a few other projects related to my own packages, I'd been thinking about picking one of those packages and volunteering to do bug triage. I don't see how anyone can find anything in the BTS when a package has hundreds of bugs, and certainly I doubt new bug reporters are really reviewing all of the existing bugs if there are more than a hundred of them. (debbugs's strong point is handling a small number of bugs on *lots* of different packages; I find it somewhat difficult to follow when dealing with a *lot* of bugs on a single package.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
