|This article brought to you by LWN subscribers|
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
Bug tracking is a perennial source of pain for distributions and other free software projects. Bug reports vary widely in quality, there is never enough developer time to even verify all of the bugs, and some bugs may get fixed in the normal course of development, entirely separate from the bug report. But bug lists that just keep growing are not terribly useful, so there is typically some kind of automatic closing of bugs that is done. The criteria for auto-closing is often contentious; finding a balance between a ballooning bug database and not irritating reporters and other users can be difficult—as a recent fedora-devel mailing list thread shows.
In some ideal world, bug reporting would go something like this:
That's where auto-closing comes into play. For Fedora, a new release of the distribution triggers the "end of life" (EOL) of the N-2 release (i.e. the release of Fedora 20 meant that Fedora 18 went EOL shortly thereafter). The project has a policy that it won't carry bug entries that only apply to EOL releases, so four weeks before the release goes EOL, a message is posted to the bug to that effect (example). If the bug is not updated to change the release it applies to, it will be closed.
In the example bug, though, David Strauss does note that the bug still affects Fedora 19, but he didn't change the release version it applies to—because he couldn't. He did not report the bug, nor does he have the privileges needed to edit all bugs, so he just posted a comment to the bugzilla entry. Thus he was a bit irritated to find that the bug had been closed:
There were suggestions to change the version on the bug (he can't), to join the Fedora BugZappers in order to get privileges needed (that group is defunct), and to file an upstream bug with X.org (as it is a driver bug). Some showed a distinct lack of sympathy for Strauss's complaint but, as Colin Macdonald put it, bugs getting automatically closed does not show Fedora as "a welcoming community to newcomers".
However, as Adam Williamson pointed out, no one has come up with a better solution yet. Not closing bugs that get comments after the EOL warning risks leaving bugs open if someone simply reports that the problem has gone away in a newer release, he said. Several thought that reports of non-working systems would be much more likely than those reporting that the bug had gone away (since those whose systems are working tend to be less attentive to bugs that got fixed).
There was some confusion in the thread, but Williamson and others clarified that the reporter can change the version (and thus leave the bug open). In the case of Strauss's bug, the reporter had stopped posting on the bug, which leaves it to the developer responsible (typically package maintainers who tend to have a lot on their plates) to notice any comments and update the bug accordingly.
Though he called it "a radical plan", Williamson suggested one possible fix: allowing anyone to reopen closed bugs. Michael Catanzaro had a different fix: just allow anyone to change the version affected by the bug. That would eliminate the problem that Strauss ran into. Matthew Miller had a more elaborate plan that would leave bugs open for one more release cycle to give users more time to respond before they get the message that their bug has been closed.
Williamson is not sure there is a real problem, partly because there are too many open bugs already, so adding more (by not auto-closing them) isn't helpful. If the bug didn't get the attention it needed, leaving it open doesn't make it any more likely that it will . But Miller noted that it is a complaint he hears regularly at conferences. When people take the time to file a bug, they are clearly hoping for more than just an eventual "closed due to EOL" message.
On the other hand, Alexander Kurtakov described the problems that package maintainers have with open bugs:
That's a common problem with bugs. And one that's not likely to be solved anytime soon.
For the EOL issues, there is a Fedora wiki entry that covers the tasks, but it still assigns handling bugzilla entries to the disbanded BugZappers group. Miller filed a bug that eventually found its way to a Fedora Engineering Steering Committee ticket. The latter resulted in some changes to the wording of the EOL message, but there may be more changes coming.
The discussion makes it clear that few are completely satisfied with the current scheme. Fedora Program Manager Jaroslav Reznik has gathered some statistics to help quantify the number of bugs closed due to EOL releases and it is substantial: roughly 6000-8000 for each release Fedora 14-18 (with Fedora 15 omitted due to lack of data).
Ultimately, the problem is rooted in the fact that many bugs get little or no attention after they are filed. If there were enough package maintainer and/or upstream developer time to address the bugs, there would be few left to auto-close. The upstream projects are typically better equipped to handle bugs in their code, which has led some to call for filing all bugs upstream.
Bug handling is often tricky and contentious. Reporters generally believe their bugs are high quality and should get immediate attention, while maintainers often find a different picture—if they have time to find anything at all. Like other projects, Fedora is trying to feel its way through something of a minefield.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds