Which bug tracker?

It is something of a recurring question in the Linux world: where should users file bug reports, with the distribution or the upstream project? There are pros and cons to each side, but there are some subtleties. Generally, the first bug report will come to the distribution, but how it should be handled from there, and who is in the best position to work with the upstream project on a bug, is sometimes contentious.

The topic came up again in a thread on the fedora-devel mailing list started by Florian Weimer, who asked about the preferred place to file bugs, enhancement requests in particular. Requests for enhancement are something of a special case, really, because they typically represent a personal preference that may or not be shared by others—the package maintainer, for example. As Rex Dieter put it, it should be up to the maintainer's discretion:

That dispensed with the feature request question for the most part, and the thread moved on to the larger question of bug reports and the responsibilities of a package maintainer. Jóhann B. Guðmundsson took a hard line on what maintainers should do:

But others were not so absolute. Many of Fedora's packagers are volunteers, so it is difficult to expect them to devote their time to working with upstream projects on bugs they may not even be able to reproduce. In those cases, it makes more sense to refer the reporter to the upstream bug tracker so that they can work with the project on solving the bug. Jeffrey Ollie outlined some of those reasons packagers may not be able, or sometimes willing, to be the go-between for the bug reporter and the project. He notes that it is not part of his regular job to maintain packages. In addition, many of the bugs reported are not those he can track down himself, but, when he can, he does try to look into the problem: "For most bug reports, I'm willing to take a little bit of time and see if there's a new release I've missed or if the bug has been already identified upstream and there's a patch that can be applied."

Guðmundsson replied with an unbending view: "Then you should not be maintaining that component". Others saw things differently, finding a bit more room for divergent opinions. Richard Shaw noted that a programming background isn't required to be a packager for Fedora, while others took umbrage at the tone. Ollie said that there is no one right answer, as it depends on a number of factors:

Package maintainers are not necessarily intimately familiar with the code for the project—or projects—they maintain. Building the code and pulling it into an RPM file is all that is really required. Having maintainers that are knowledgeable about the code is certainly desirable, but may not be all that realistic. Given that, it probably makes sense not to have a rigid policy. Eric Smith put it this way:

But, as Ian Pilcher pointed out, bugs filed upstream by a package maintainer may carry more weight than a user's bug would. It is not a malicious act by the project, he said, more of a "social triage" to try to separate the wheat from the chaff. "In many cases, the Fedora packager has built up a level of credibility with the development community that could get a bug report the attention that it deserves."

The Fedora package maintainer responsibilities document contains a lot of suggestions for how packagers should work with upstreams, but doesn't actually require all that much. For example, it is recommended that packagers "forward severe bugs upstream when possible for assistance". It also suggests that bugs reported be dealt with in a timely manner, possibly with the assistance of co-maintainers or others more familiar with the code (including the upstream project).

Bug reports vary widely in their quality, but those generated from distributions are often not very applicable upstream as well. Distributions tend to lag project releases, so the version that the distribution user is reporting a bug against may well be one or more releases behind the project's version. Many projects aren't terribly interested in bugs in older versions, and would rather see whether the bug exists in the latest release. Other projects are only interested in bugs that are reproducible in the latest code in their source code repository. In either of those cases it may be difficult for a user (or even a packager) to determine whether the bug is still present, which just throws up one more barrier to bug reporting.

Systems like Ubuntu's Launchpad, where upstream bugs can be linked to the distribution bug report may help, but don't solve some of the underlying problems inherent in bug reporting. Bug handling is not primarily a technical problem, though some technical measures may help. Getting better bug reports from users, with reproducible test cases and all the required information is, to a large extent, a social problem.

Back in early 2011, we looked at a similar discussion in the Debian community, which touched on earlier Fedora struggles with the problem as well. Handling bugs is tricky for any number of reasons, and it is hard to imagine that there is "one true policy" out there that would alleviate most or all of the problems. Proper bug handling just depends on too many variables to make any kind of rational, hard-and-fast rules about it. Discussions like these can only help devising guidelines and best practices, though, and we will undoubtedly see them pop up again.