Reporting bugs upstream
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:
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:
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:
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:
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).
Posted Jan 20, 2011 1:50 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
Posted Jan 20, 2011 6:27 UTC (Thu)
by dirtyepic (guest, #30178)
[Link]
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.
Posted Mar 7, 2011 18:58 UTC (Mon)
by gvy (guest, #11981)
[Link]
Posted Jan 20, 2011 2:44 UTC (Thu)
by modernjazz (guest, #4185)
[Link]
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.
Posted Jan 20, 2011 5:00 UTC (Thu)
by dberkholz (guest, #23346)
[Link] (1 responses)
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.
Posted Jan 22, 2011 4:49 UTC (Sat)
by steffen780 (guest, #68142)
[Link]
Posted Jan 20, 2011 6:09 UTC (Thu)
by arief (guest, #58729)
[Link] (5 responses)
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 :-)
Posted Jan 20, 2011 8:11 UTC (Thu)
by dambacher (subscriber, #1710)
[Link] (4 responses)
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.
Posted Jan 20, 2011 8:20 UTC (Thu)
by burki99 (subscriber, #17149)
[Link] (2 responses)
Posted Jan 20, 2011 11:50 UTC (Thu)
by njwhite (guest, #51848)
[Link] (1 responses)
They don't seem to have caught on yet. I still like the idea, though.
Posted Jan 20, 2011 16:42 UTC (Thu)
by jtc (guest, #6246)
[Link]
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.
Posted Jan 23, 2011 17:20 UTC (Sun)
by ccurtis (guest, #49713)
[Link]
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).
Posted Jan 20, 2011 9:11 UTC (Thu)
by pcampe (guest, #28223)
[Link] (2 responses)
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.
Posted Jan 20, 2011 15:04 UTC (Thu)
by C.Gherardi (guest, #4233)
[Link] (1 responses)
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.
Posted Jan 20, 2011 19:45 UTC (Thu)
by jrn (subscriber, #64214)
[Link]
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).
Posted Jan 20, 2011 9:16 UTC (Thu)
by mjthayer (guest, #39183)
[Link]
Having said that I am now tempted to proactively give it a try for a couple of distributions...
Posted Jan 20, 2011 10:51 UTC (Thu)
by Eliot (guest, #19701)
[Link] (1 responses)
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.)
Posted Jan 20, 2011 13:00 UTC (Thu)
by sorpigal (guest, #36106)
[Link]
Posted Jan 20, 2011 13:28 UTC (Thu)
by jengelh (guest, #33263)
[Link]
Posted Jan 20, 2011 18:37 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
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.
Posted Jan 20, 2011 19:38 UTC (Thu)
by ejr (subscriber, #51652)
[Link] (3 responses)
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.
Posted Jan 21, 2011 23:25 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (2 responses)
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.
Posted Jan 23, 2011 19:41 UTC (Sun)
by loevborg (guest, #51779)
[Link] (1 responses)
Posted Jan 23, 2011 20:51 UTC (Sun)
by Darkmere (subscriber, #53695)
[Link]
Posted Jan 20, 2011 21:27 UTC (Thu)
by amcnabb (guest, #56959)
[Link]
Posted Jan 21, 2011 6:58 UTC (Fri)
by zooko (guest, #2589)
[Link]
https://bugs.launchpad.net/fedora/+source/binutils/+bug/4...
Posted Jan 21, 2011 8:24 UTC (Fri)
by madcoder (guest, #30027)
[Link]
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...
Posted Jan 21, 2011 12:59 UTC (Fri)
by dneary (guest, #55185)
[Link]
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.
Posted Jan 24, 2011 19:19 UTC (Mon)
by Baylink (guest, #755)
[Link] (1 responses)
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.
Posted Jan 24, 2011 23:01 UTC (Mon)
by dlang (guest, #313)
[Link]
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.
Posted Jan 25, 2011 2:20 UTC (Tue)
by Baylink (guest, #755)
[Link]
All I know about it is that it exists. :-)
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
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
In Gentoo...
In Gentoo...
Bug tracking system as social media?
Bug tracking system like git reversed
Bug tracking system like git reversed
Bug tracking system like git reversed
Bug tracking system like git reversed
All BTSs should use SMTP
Another solution could be to create a protocol wich enables bug tracking systems to __share_bugs__.
Reporting bugs upstream
>his because the user doesn't want to spend 30 seconds creating an account
>on an upstream BTS.
Reporting bugs upstream
- Dev/maintainer adds users email address to the issue to be cc'd on updates
- Tracker sends an email to that address 'You have been added as a watcher for issue - click link AAA to receive updates to this issue, or ignore this message if you dont wish to receive updates.'
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
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
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
I've always thought of Debian's bug system as triage
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream
Reporting bugs upstream