Adrian Bunk <b...@stusta.de> writes: > "no one is ever going to look at the bug again" is actually impossible > to prove for a project like Debian - some new Debian developer or even > some new upstream developer might actually look at it tomorrow or in a > few years.
Yeah, I know, and this is a valid point, and is the reason why we all keep some bugs around. And there's some merit to doing that. But I think we generally keep too many bugs around. We've had this conversation a few times before on debian-devel, without reaching much in the way of an actionable conclusion. But it's very hard to do bug triage for popular, large software packages (the kernel, the X stack, GNOME, that sort of thing). Even if you filter out unactionable bugs, there are so many bugs that look reasonable in isolation, but the math indicates that most of them will simply never be addressed. The other angle on this that people underestimate is that most bug reports have a useful lifetime. I've certainly done my share of resolving really old bug reports, and it's quite satisfying when it happens. But it's also very common to look at old bugs and realize that the world has changed and the software has changed to the point where the bug report doesn't really apply. Or, even harder to detect, the original bug reporter doesn't have the same problem any more or isn't even using the software, and no one else has cared (which is impossible to measure, sadly). Or the problem has subsequently been reported in some fresher bug that people are actively working on. This is why, in a work environment, it's usually someone's job (and has often been my job) to do backlog grooming, close out bugs that have become irrelevant, close out bugs whose priority is so low that no one should be working on them, and try to keep the backlog actionable. Now, the sort of aggressive grooming you do in a job isn't appropriate for a volunteer activity without some changes. For one, there's no agreed-on priority across all contributors; one person's low-priority bug may be someone else's starter project. So it's much less useful to close out bugs purely on a priority basis. And, as you say, there's no way to know for certain that you won't get a sudden influx of volunteer activity (although I think we have to be realistic about how likely that is). But still, despite all of those caveats, I do think there are a few things that are fairly clear-cut. If the package has 3,000 open bugs, just close out the unactionable reports in some polite and constructive way. At that point, there are so many actionable bugs ahead in the queue that those reports are adding clutter and making it harder for people to get a handle on the bugs that can be directly addressed by the package maintainers. > So allowing users to report bugs against stable does often already > create unrealistic expectations like "someone will look at the bug" or > even "the bug will be fixed in stable". Yeah, bug reports against stable are another very tricky area in Debian. There are packages where they will be addressed; for example, I have a lot of packages with <10 (and often 0) bug reports, and I will look at and try to resolve bugs against stable on those packages. But for something like GNOME, it's unrealistic to expect much resolution of bugs only in stable unless they're particularly severe. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
