Reporting bugs upstream [LWN.net]

By Jake Edge
January 19, 2011

Bug reports from users are an important way for projects to find and eventually fix problems in their code. For most Linux users, though, the code from those projects makes its way to them via distributions, so that's where they report any bugs they find. What happens next is something of an open question, as a thread on the debian-devel mailing list highlights. Should it be up to the bug reporter to push the bug upstream if it is found to not be specific to the distribution? Or should it be up to the package maintainer?

Brian M. Carlson started the thread by noting that he has been frequently asked recently to forward bugs reported to the Debian bug tracking system (BTS) to upstream projects. For a number of reasons, he doesn't think that's the right way to deal with these bugs:

I understand that maintainers' time is limited and that forwarding bugs is not an enjoyable task. But I also understand that having a BTS account for the upstream BTS of each of the 2405 packages I have installed on my laptop (not to mention my other machines) is simply not practical. I also don't have the benefit of the rapport that a maintainer has with upstream and knowledge of upstream practices.

Essentially, Carlson is arguing that package maintainers already have the requisite relationships and accounts to properly move the bug upstream, whereas a regular user, even one who is fairly technically sophisticated, will not. But, of course, it is the user who has the intimate knowledge of the bug and can hopefully reproduce it or at least give the upstream developers a better idea of how to. Inserting the package maintainer into the middle of the bug triaging/fixing process may just slow things down. Unfortunately, most bug tracking systems don't provide a way for users without accounts to be copied on bug report traffic, which leads back to the problem that Carlson identified: users aren't interested in creating an account for each project's bug tracker, instead they rely on their distribution to upstream bugs.

In addition, it may well be that the user doesn't really have the knowledge necessary to interact with upstream, especially for distributions that target less-technical users. Many of the bug reports that come into any bug tracker (Debian's, other distributions', or the projects') are inadequate for various reasons, so forwarding them or asking the user to report them upstream is pointless—potentially counterproductive because it annoys the upstream developers.

It comes down to a question of what the responsibilities of a package maintainer are. Many seem to take a proactive approach by trying to reproduce the problem and, if they can, reporting it upstream. Others, though, are completely swamped by the sheer number of bugs that get reported, finding it difficult to do more than try to determine if the bug is Debian-specific and asking for it to be reported upstream if it isn't.

There is a large disparity in the size of the packages that are maintained by Debian (or any other distribution), of course. Some smaller or less-popular packages may allow their maintainers to keep up with the bugs and shepherd those that deserve it upstream. While other, larger packages, like the kernel, X, GNOME, KDE, LibreOffice, and so on, just don't have enough people or time to do that. Thus it is very unlikely that there can be a "one size fits all" solution; each package and maintainer may necessarily have their own bug management style.

John Goerzen explained how the process works for the Debian package of the Bacula backup program, noting that he sits between the bug reporter and the upstream project, but that it is often wasted effort:

I'm adding zero value here. Zero. It is a huge and frustrating waste of my time. It is also frustrating for upstream, who would rather just talk with the user directly and involve me if they think there's a Debian-specific question. I don't understand why some users want it to go this way, but many clearly do despite the fact that they get worse service.

Being a "copy and paste monkey between emails and web forms" is not what he wants to be doing. He points out that various unnamed major packages tend to just ignore many of their bug reports for years at a time. Overall, he doesn't think that being a maintainer should necessitate being a bug intermediary as well:

But really, I think it is nonsensical for an end user to expect me to do this because the user doesn't want to spend 30 seconds creating an account on an upstream BTS. That's not what Free Software is all about. And it has Debian maintainers wasting time.

I think that promising that Debian maintainers will always shepherd bugs upstream is promising something we don't actually deliver on very well, and probably never have. Perhaps we should stop promising it.

Ben Finney (and others) see it as, at least partially, a technical problem in the bug tracking software. While requiring bug reporters and those copied on the bug comments to be registered in the system may make sense—for reducing spam problems if nothing else—it definitely puts up a barrier for users:

Quite the opposite, from my position. A great feature of the Debian BTS is that any user can interact with it through a standard interface without maintaining multiple separate identities; heck, without having to create a single new identity at all.

Having to create and maintain (or fail to maintain) identities with balkanised upstream BTSen is bad enough as a package maintainer. As a mere user of all the other packages on my computers, I consider it too high a barrier.

Finney looks at the problem as an opportunity to try to find better technical solutions. There may be ways to enhance the Debian BTS to file bugs upstream and/or CC the Debian bug reporter on upstream questions, as Don Armstrong suggests. Ubuntu's Launchpad has made some efforts to link downstream and upstream bugs to address some parts of the problem, but it is more than just a technical problem as various posters pointed out.

Many upstream projects are largely uninterested in bugs reported against older versions of their code. Unless the bug can be reproduced in the latest release—or sometimes the latest commit to the project's source code repository—it may not be investigated at all, even if the bug is reported upstream. It is not just package maintainers that have far more work, and bugs, than they can possibly deal with.

But distributions have something of a contract with their users to support the package versions that make up the distribution release. It can be very difficult to have a user test with updated versions of the code in question to try to reproduce the problem. Bugs that can be easily reproduced are obviously much easier to handle, but they are also, seemingly, much less common.

Fedora has struggled with similar issues, including discussions last July on the fedora-devel and test mailing lists; undoubtedly other distributions have as well. Also, it isn't just the distribution and user side that suffers, as there have been cases where bugs and fixes known to downstream distributions haven't made their way upstream. It would seem that there is an opportunity for projects and distributions to work more closely together, but that won't be easy given the workloads on both ends of the stream.

Bug reports are a difficult problem in general, as good reports are sometimes hard to find. There may also be a few layers between the reporter and someone who might be able to actually fix the problem, which can cause all manner of frustrations for anyone involved. On the bright side, though, the situation is far better than the proprietary software world, where reporting a bug may require paying for a "trouble ticket" and waiting for a release that actually addresses it. At least free software allows an interested hacker to poke around in the code and fix it for themselves (or their customers).

The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:

Note: you can avoid this step in the future by logging into your LWN account.