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
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
mailing lists; undoubtedly other distributions have as well. Also, it
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
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).
to post comments)