Weekly Edition
Return to the Front page
| |||||||||||||
Reporting bugs upstreamBug 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). (Log in to post comments)
Reporting bugs upstream Posted Jan 20, 2011 1:50 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] I would say that it depends on the bug. For bugs that depend on the end user's hardware configuration, intermittent failures and the like, the distro package maintainer really doesn't have anything useful to contribute; upstream and the end user will need to communicate directly. But for common, reproducible bugs, upstream is probably better off dealing with a few distro package managers than with all the end users.
Reporting bugs upstream Posted Jan 20, 2011 6:27 UTC (Thu) by dirtyepic (subscriber, #30178) [Link]
Exactly. If a distro maintainer can reproduce the bug then they should be the ones going to upstream. They most likely already have a relationship with upstream, even if it's just knowing where to report bugs, what mailing lists to use, etc. They are also more likely to be familiar with the code base and know what the bug is, why it's broken, and how it could be fixed than a random user would be.
If the maintainer can't reproduce the bug or the user knows more about the package/bug in question, then sure, it's appropriate to ask them to file the report. But this should be the exception, not the rule.
Reporting bugs upstream Posted Mar 7, 2011 18:58 UTC (Mon) by gvy (guest, #11981) [Link]
It also depends on maintainer (see "generalists vs specialists" issue): while a specialist maintaining a few packages or even a single one _can_ have the benefit of being thoroughly involved with upstream, a generalist messing with a few dozens (or hundreds) likely has a lower chance for being well into a _particular_ one.
Reporting bugs upstream Posted Jan 20, 2011 2:44 UTC (Thu) by modernjazz (guest, #4185) [Link]
For a while, it was not clear to me that distributions like (K)Ubuntu lacked a plan to do anything about bugs that were not packaging bugs. So a lot of bug reports languished uselessly.
Either I've finally been trained, or they are getting better about communicating that almost all bugs reports should be filed upstream. From my perspective, clearer communication has gone a long way towards solving the major problem.
In Gentoo... Posted Jan 20, 2011 5:00 UTC (Thu) by dberkholz (subscriber, #23346) [Link]
In Gentoo, what I've done is ask users to pass bugs through us first. If they appear to be upstream issues, we ask them to file upstream bugs but CC us, and we try to provide help on how a particular project likes its bugs reported. This keeps us in the loop so that we can track progress (and make sure some actually happens) as well as help either side where needed.
The point made by Brian Carlson seems to be a strawman to me. Is he actually filing a bug for every one of those 2,405 packages? If so, he clearly has a lot of free time on his hands and can probably afford another 30 seconds to register for a bug tracker for each since of course writing a good bug report takes much longer than that.
In Gentoo... Posted Jan 22, 2011 4:49 UTC (Sat) by steffen780 (guest, #68142) [Link]
As a very happy Gentoo user I want to say +1 to this. I've reported bugs in Gentoo and upstream many times and I never considered it an undue burden to do so. Yes, some bug trackers are a bit confusing, and if the maintainer of a distro-package wishes bugs reported to her first then that's great and I'm sure we all appreciate them taking on extra work for us. But trying to establish that as SOP seems unreasonable to me.
Bug tracking system as social media? Posted Jan 20, 2011 6:09 UTC (Thu) by arief (guest, #58729) [Link]
One idea that comes to mind is, could we somehow come up with a BTS that works like a social media and enables collaboration?
Say have a package or software registered as bts-social.com/packagename that any users or package maintainers can be subscribed or linked to and file bug reports in there.
There could be alot of other stuffs could be done if we have it this way. Like experience sharing, contributions and/or donations, # of users tracking, distro tracking, license tracking, etc.
Then again, I dont have much experience in this area to judge whether this is a good idea, or a complete laughable-nothing-to-see stupid non-sense :-)
Bug tracking system like git reversed Posted Jan 20, 2011 8:11 UTC (Thu) by dambacher (subscriber, #1710) [Link]
Another solution could be to create a protocol wich enables bug tracking systems to __share_bugs__.
This way the maintainer of a package could look over the bug and figure out if action is needed or pass it upstream to the projects bug system with one click - or automatically...
And if upstream works on the bug, subsequent posts get played back to the original reporter on his bug system. He will then be pleased to see that something is happening at least.
Bug tracking system like git reversed Posted Jan 20, 2011 8:20 UTC (Thu) by burki99 (subscriber, #17149) [Link]
Exactly my thought - we would need something like git-bug with the possibility to push/pull the reports from one tree to the next if they apply there as well. Not sure if it is technically feasible, but it seems Bugzilla (or similar systems) are to CVS as git is to the system to be invented.
Bug tracking system like git reversed Posted Jan 20, 2011 11:50 UTC (Thu) by njwhite (subscriber, #51848) [Link]
Distributed bug trackers were covered in 2008: https://lwn.net/Articles/281849/
They don't seem to have caught on yet. I still like the idea, though.
Bug tracking system like git reversed Posted Jan 20, 2011 16:42 UTC (Thu) by jtc (subscriber, #6246) [Link]
"Distributed bug trackers were covered in 2008 ..."
The idea I had is similar, but perhaps it involves less infrastructure/work (or maybe not): The distribution's bug tracking system is registered (it has its own, perhaps non-respond-to-able, email address) with each upstream package's bug tracker. When a user files a bug for package X, the bug report is forwarded automatically to the upstream package's system, which is allowed by the upstream's tracker because the distribution's tracker is registered. (The easiest way for the sender to do this is probably email. Is it feasible on the receiver's side? It seems, to me, to be reasonable, perhaps even expected, as a feature request.) The reporting user's address is included in the (upstream) bug report so that he/she can be contacted by the actual developer.
All BTSs should use SMTP Posted Jan 23, 2011 17:20 UTC (Sun) by ccurtis (guest, #49713) [Link] Another solution could be to create a protocol wich enables bug tracking systems to __share_bugs__. The way I'd phrase this is: Every BTS must provide a bug-level SMTP gateway. Debian already has a head start here, and I know bugzilla has (or had) patches for this, but a good process seems to me to be:
Now there is two-way communications from the bug reporter to the upstream project, traversing both the distro and upstream BTS. The maintainer could effectively zone out at this point, only watching the traffic to close the bug report when it is closed upstream. The user only has to interact with their distro bug reporting tool, which makes it simpler for them. This doesn't seem to me like an unreasonable burden on the package maintainer, and they only become a cut-n-paste monkey if the user's bug report is perfect from the outset, which is quite unlikely. The value add is that the maintainer knows how to file upstream bugs properly, which reduces wasted time, and it makes things simple for the end user. If "world domination" is still a goal, an intermediary will be needed between upstreams and these simplest of users. The typical upstream response ("Try this patch...") may fall on deaf ears, but there's a simple fallback: "Wait for the next version", which is what people are accustomed to. A very proactive maintainer could do the compiling for the end user - which would be very nice - but is more likely to be a feature of Ubuntu or Red Hat (where people are paid to do such things) than of a volunteer group. The only big issue I see is SMTP bugspam, where a social-network like trust system could be helpful, albeit perhaps overkill. A simpler permission list should suffice - perhaps even at the SMTP gateway level (e.g, bug#@bts.upstream.com).
Reporting bugs upstream Posted Jan 20, 2011 9:11 UTC (Thu) by pcampe (guest, #28223) [Link]
>But really, I think it is nonsensical for an end user to expect me to do
>his because the user doesn't want to spend 30 seconds creating an account >on an upstream BTS.
This can be easily fixed using a single sign-on solution, like OpenID (just to name one): it should not be difficult to define a federation of web sites (BTS sites) and allow a user to have just an account, and not potentially hundreds of them.
On the same time, it seems to me that is possible to define some XML-based format to exchange bug information, at least to avoid the maintainer to work as a monkey operator.
Of course, these won't solve the problem, but to say the least we have some technological options to deploy to alleviate users' and maintainers' frustration.
Reporting bugs upstream Posted Jan 20, 2011 15:04 UTC (Thu) by C.Gherardi (subscriber, #4233) [Link]
You could ask the question just as legitimately 'Why dont developers of upstream projects all have accounts in the distribution trackers, so they can be added as cc to relevant bugs by maintainers?'.
I'm up to at least 30 accounts in various bug trackers and forums. I have not reported or commented issues because I needed to register for 'another damn throwaway registration', and I'm a developer of a small open source project.
Single sign-on is only part of the issue. It would certainly help for certain cases. Most of my userbase doesn't have a sourceforge account where the project is hosted, and bug reports come via a non-sourceforge forum.
I would dearly love the ability to be able to add an email address to the bug tracker so the user has visibility of the issue without having to register.
A simple feature for bug trackers would be:
The user is kept in the loop if they want, and developers of upstream projects could be included in the same way if they need direct contact with the user.
The registration code is already in place for public trackers.
Reporting bugs upstream Posted Jan 20, 2011 19:45 UTC (Thu) by jrn (subscriber, #64214) [Link]
> You could ask the question just as legitimately 'Why dont developers of upstream projects all have accounts in the distribution trackers, so they can be added as cc to relevant bugs by maintainers?'.
In the case of the Debian bug tracking system, you don't need an account. The bug tracking software is basically a glorified mail archive for a collection of per-bug public mailing lists (and works very well).
Reporting bugs upstream Posted Jan 20, 2011 9:16 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
With an upstream maintainer's hat on, for a large-ish project, one solution that I see would be for distribution maintainers - after politely asking whether upstream is interested - to simply add an upstream contact on to the CC list for a package, so that that contact gets notified when the distribution decides that a bug belongs to their package. That way both the distribution people and upstream would see the bug and be able to decide whether they want to do anything with it or simply ignore it as not relevant to them. It would also give me the opportunity to decide in advance that I don't want to see bugs for whatever outdated version of the software if that were the case. And creating accounts with the ten or fifteen most interesting distributions (not naming any names...) seems manageable.
Having said that I am now tempted to proactively give it a try for a couple of distributions...
Reporting bugs upstream Posted Jan 20, 2011 10:51 UTC (Thu) by Eliot (subscriber, #19701) [Link]
As a user, it is sometime hard to know where to find 'upstream BTS'.
The distro in the ideal position to know where "upstream" for each package is. So perhaps part of the answer is for the distro to 'package' some info about where the upstream BTS is so users can find it in a consistent way, (along with the usual binaries and source of the package.)
Reporting bugs upstream Posted Jan 20, 2011 13:00 UTC (Thu) by sorpigal (subscriber, #36106) [Link] Or go one step further and have some way to either automatically forward the report upstream and CC the user, or at least to dump upstream contact info into an email to the user when closing the a bug that should be reported upstream.
Reporting bugs upstream Posted Jan 20, 2011 13:28 UTC (Thu) by jengelh (subscriber, #33263) [Link]
The account creation really is annoying, especially when you have to remember passwords. That is why I had set all my SF projects to allow anonymous tracker postings, and set up mailing lists. Such is essential for users wishing to fire-and-forget (and reappear later).
Reporting bugs upstream Posted Jan 20, 2011 18:37 UTC (Thu) by iabervon (subscriber, #722) [Link]
It seems to me like the best thing for the technical aspects would be for Bugzilla to implement OpenID both as a consumer (was written once, didn't get merged, bitrotted) and as a producer (new idea). You register with your distro Bugzilla, and file your initial bug there (with the idea that your direct problem has to be fixed by your distro, likely by taking a newer version of the upstream package or at least backporting the patch that fixes the bug). If an upstream bug needs to be filed, you file it with your distro Bugzilla account authenticated via OpenID. The upstream Bugzilla then sends messages to your distro Bugzilla account (which is what you authenticated as), and that emails you after sanity-checking the message (principally, checking whether it's from a Bugzilla registered as the upstream for a package that you've filed a distro bug about; potentially, the messages could include machine-readable information as to what happened, so the distro Bugzilla could filter messages based on your email preferences).
This seems to me like it would be a relatively self-contained feature, aside from the fact that it needs both sites to support it before it's useful. For that matter, it could be useful between projects as well; Firefox users report bugs to Mozilla with WebGL which are due to Mesa driver flaws, so it would be useful to be able to report a Mesa bug while identifying yourself as a Mozilla bug reporter.
Reporting bugs upstream Posted Jan 20, 2011 19:38 UTC (Thu) by ejr (subscriber, #51652) [Link]
As a user, I've always thought of Debian's bug system as triage. There may be issues related to Debian packaging or interactions within Debian. Those likely are unrelated to the upstream bug system. There also are users who don't respond, report PEBKAC, etc.
Past that, Debian's BTS serves (in my non-maintainer mind) as a way to track and merge reports before submitting upstream. I'm not sure what tools exist to link a Debian BTS merged report into an upstream report, however.
Reporting bugs upstream Posted Jan 21, 2011 23:25 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I've always thought of Debian's bug system as triage That's not really triage; it's just screening. Triage is a concept from battlefield medicine where you divide patients into three categories (hence the "tri" in the name):
It really only applies in situations with time pressure.
Reporting bugs upstream Posted Jan 23, 2011 19:41 UTC (Sun) by loevborg (guest, #51779) [Link]
At least the etymological part of your claim about "triage" is clearly false. The word seems to be derived from Old French "trier": try (http://dictionary.reference.com/browse/triage).
Reporting bugs upstream Posted Jan 23, 2011 20:51 UTC (Sun) by Darkmere (subscriber, #53695) [Link]
http://www.etymonline.com/index.php?search=triage&sea... also adds some insight.
Reporting bugs upstream Posted Jan 20, 2011 21:27 UTC (Thu) by amcnabb (subscriber, #56959) [Link]
My thought is that upstream projects should try to be involved with the bug databases for a few major distributions. If developers would interact with users on the Fedora and Ubuntu bug databases, then the maintainers can focus on distribution-specific bugs. The article mentions that it's not too hard for a user to create dozens of accounts on upstream bug trackers, so it should be even easier for developers to register with two or three distributions.
Reporting bugs upstream Posted Jan 21, 2011 6:58 UTC (Fri) by zooko (subscriber, #2589) [Link]
This is what I use launchpad for--tracking issues which affect multiple projects and/or distributions. Here's a good example of a bug which affected several different projects and several different distributions:
https://bugs.launchpad.net/fedora/+source/binutils/+bug/4...
Reporting bugs upstream Posted Jan 21, 2011 8:24 UTC (Fri) by madcoder (subscriber, #30027) [Link]
As a user and a Debian Developper, what is the most annoying is having to be forced to create accounts to the upstream bug trackers.
This is exactly why I report bugs to debian, because tools are integrated in my distro, I don't need to create accounts on a zillion bugzillas or worse bug-trackers.
OTOH, I usually make detailed enough bugs, so that it doesn't require too much back and forths through the Maintainer...
Reporting bugs upstream Posted Jan 21, 2011 12:59 UTC (Fri) by dneary (subscriber, #55185) [Link]
Coincidentally, I recently wrote about an issue related to this in "what does it mean to maintain a package?": http://www.neary-consulting.com/index.php/2011/01/13/what...
While copying & pasting is not nice, sending bugs upstream is an important part of the job. I have no problem with maintainers sending bug reporters upstream, even if they are not keen.
One problem that I also highlighted is that there's typically 12 months or more between code getting written and getting into the hands of a substantial number of users via distros: http://www.neary-consulting.com/index.php/2011/01/14/the-... - the solution, I think, is for distro package maintainers to collaborate on the maintenance of older stable releases of code that project maintainers are not interested in any more.
Dave.
Reporting bugs upstream Posted Jan 24, 2011 19:19 UTC (Mon) by Baylink (subscriber, #755) [Link]
> distributions have something of a contract with their users to support the package versions that make up the distribution release.
And this is the crux of the issue.
I concur entirely with this observation; that's what a distribution *is for*. It's a *collection* of packages, all installed together and -- theoretically -- chosen so as to interact well.
I entirely understand that there's a size in the middle between OpenSUSE (which is Big Enough, in theory, to do this well) and Puppy/DSL, which is so *small* that it can do it well, and that distros in the Donut Hole will have trouble with it.
But if a distribution in the middle wants to disclaim this particular responsibility, I think it ought to do so *explicitly*, myself.
That said, extending the technology through which we report bugs such that distro packaging managers can escalate a bug right out to the package developer's BTS would be a Really Good Thing -- especially given the number of rollup BTSs we have these days.
Reporting bugs upstream Posted Jan 24, 2011 23:01 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
if you want the distros in the middle to do so explicitly, but don't think the very large or very small distros need to, how in the world is a user supposed to know what category the distro falls into?
I think that the users should assume that their distro is doing this work, and if the distro chooses not to, they should say so explicitly.
Reporting bugs upstream Posted Jan 25, 2011 2:20 UTC (Tue) by Baylink (subscriber, #755) [Link]
FWIW: I've just learned tonight, in checking out Best Practical software to look into RT 4.0, that they *have* a networkable bug reporting/tracking package called SD (Simple Defects).
All I know about it is that it exists. :-)
|
|||||||||||||