When bugtracking systems are fences, not bridges

Submitted by dag on Thu, 2008/12/11 - 23:03

Today, in my quest for a media center solution that suits me, I started fixing some issues with running Elisa on CentOS 5. Elisa looks very interesting in the sense that it is written in python, it is a relative young project and it is esthetically pleasing (more than one of the other projects I investigated). And soon in RPMforge for CentOS (albeit not without issues yet).

The only downside at the moment is that it does not do TV viewing from a screengrabber or MPEG encoder card, so it is not the replacement I was looking for.

The Elisa project is using Launchpad for bugtracking and project management and so I created an account to send a few patches. I also took the time to see how Launchpad worked feature-wise and while doing that searched for some of my own projects that are part of Ubuntu. Launchpad looks nice, with a lot of attention to workflow and lowering the barrier for people to report issues and work together.

However what I found was a few bugreports, some for known issues and some for new issues I haven't heard of. Now the sad part is that nobody contacted me (upstream) regarding these issues. And nobody was fixing them either, let alone commenting on them.

Comparing this with Debian bugtracking system, I was notified by the maintainer when the package went into Debian, get all reported bugs send to me (upstream) and I always took care of fixing them and marking the bug number in the ChangeLog. Not so for Ubuntu, and to be fair, not with Fedora, OpenSUSE or Gentoo either.

Not only is this a lost opportunity, it is a bad service to both upstream and the user itself. Without a bugtracking system, users would directly contact upstream. Now with Launchpad users report their bugs and nothing is done with them. Not by the maintainer and not by (unaware) upstream. And they are not being send to Debian (their upstream) either.

And this is not specific to Launchpad per se, I have similar remarks for Fedora's bugzilla or OpenSUSE. I have no clue what bugs are reported regarding my tools, nor have I been contacted to be involved. I should be commending Debian for doing what is right and expected. Maybe it is the responsibility of the maintainer to communicate with upstream, but Debian's automated system clearly works much better in that respect than any of the other distributions. The process takes care of that.

So there is a lot we, as a community, can improve by connecting users to upstream, or rather, by connecting bugtracking systems to upstream for the benefit of all.

PS I for one am interested to subscribe to dstat, unoconv, mrepo and dconf bugreports for Fedora, OpenSUSE, gentoo and others if I knew how to do that.

Update: I changed the title because bugtracking systems are not being fenced, they are fences.

I'd like to point out that

I'd like to point out that not all software authors want Launchpad or Bugzilla reports in their inbox, though, especially newbie questions or esoteric packaging discussions. Opt-in may or may not be the best policy. Personally I try to alert upstream myself when it appears to be a real bug.

For Fedora or RHEL, you can get an RSS feed from Bugzilla. Do any search (such as Advanced Search with Component "dstat") and then click the "FEED" link at the bottom. Personally I did that search once and then created a Firefox smart search to replace the "component=" string with whatever package I want.

Looks like there aren't any dstat bugs right now, but here are CLOSED dstat bugs, for example.

Hey Joshua, I can understand

Hey Joshua,

I can understand that not everyone wants these reports. But by not notifying upstream at least once you loose out everyone else too. I do agree it should be opt-in though.

PS I really dislike an RSS feed for tracking bugs. Much rather have everything consolidated into my mailbox.

PS2 The way Launchpad creates a community around a package is much more advanced than doing queries in tools.


rss2email could do that. Stopgap solution, I know.

Hey, but it's easy to subscribe to the package's bugs

It's a bit ironic that about 2 years ago Jorge Castro and I, as an experiment, wrote to a sample of upstreams and asked them if they'd like to be notified of Ubuntu bugs through Launchpad. We were pretty uniformy ignored or shrugged off as trying to get upstreams worried about Ubuntu bugs -- "not our bugs and not our problem". In our hearts we know that many upstreams do want to get these reports -- but finding you is hard!

I know you've figured it out, but for a complete answer, right now it's pretty easy to get notifications of bugs in any package: just visit the package's page and subscribe to its bugmail. So, for dstat: https://edge.launchpad.net/ubuntu/+source/dstat and choose "Subscribe to bug mail". That's it.

For bonus points, we let you filter bugmail in a lot of different ways:
https://help.launchpad.net/Bugs/Subscriptions#headers -- and you can actually reply and manipulate bugs through email too, just like with debbugs: https://help.launchpad.net/Bugs/EmailInterface

Hey Joshua, Awaiting a proper

Hey Joshua,

Awaiting a proper solution I updated my Red Hat and CentOS search page and implemented the Firefox "smart" search you were talking about.

I hope it can help other people, but one thing that would benefit the Red Hat and CentOS community would be the ability to search Red Hat Bugzilla content on Google.

Media center

Have you looked at Freevo? http://freevo.sf.net

It is a solid media center frontend to standard Linux media tools.Once setup it does a good job of being easy to use via remote.

Launchpad and Upstream Bug Trackers

I'm a member of the Launchpad development team and my major remit at present is improving the way that works with upstream bug trackers.

We've made a number of strides in the right direction recently, and we'll be continuing to do so over the coming months. Specifically, we've now got support for syncing comments with certain upstream bug trackers and we're working on syncing whole bug reports with upstream bug trackers, too. It will eventually be possible to forward bugs in Launchpad upstream without ever having to leave the context of Launchpad itself (though we're a little way of that yet and we have yet to decide how best to address the issue that a commenter raised above, namely that of which bugs are good enough to get forwarded upstream and who has the right to do so).

Part of the problem with this is that bug trackers simply aren't designed to talk to one another in the way that they should be. We're working hard on improving the way that Launchpad does this work, and in providing a public API to Launchpad we're giving other developers the opportunity to interface with us for exactly this purpose (and others), however at the moment our best upstream syncing work requires the remote bug tracker to install an API plugin (available at the moment for Trac and Bugzilla) so that Launchpad can communicate with them efficiently.

What is really needed is for the major bug tracker developers to sit down and work out a common interface that all bug trackers can implement to allow proper upstream forwarding (and, where desired, downstream syncing). The task isn't trivial but it is solvable and I see no reason why it can't be solved in the near future.

packages not on opensuse?


I don't find dstat, unoconv, mrepo and dconf in openSUSE ... do you have the bugzilla links for instance?

Ciao, Marcus

Honestly, I do not know :-/

Hey Marcus,

I know that dstat has an OpenSUSE package, the homepage has a link to it. I think Pascal Bleser was involved with that package.

I don't know about the other tools (I probably should google) and that is part of what the article was about. It would benefit the community if upstream knew that a tool was packaged for the distribution and that upstream is involved with any reported issues.

Currently it mostly depends on the goodwill of the packager instead of being part of the workflow.

There are many of us in this boat...


I'm Jesse, the author of RT (http://bestpractical.com/rt) and one of the creators of SD (http://syncwith.us), a peer to peer issue tracking tool.

SD is a little different than the other distributed bugtrackers in that it's designed to be able to sync with foreign systems. Right now, we only have sync protocol adaptors for RT and for Hiveminder.com, though we've started looking at Trac, Debbugs and Launchapd).

The goal is to let you do...pretty much what you're looking for.

We'd be absolutely thrilled to have more folks using SD and working to make SD talk to more foreign systems.

@gmb - I'd be absolutely thrilled to be involved in sorting out a proper interop protocol. We've done some work to make RT sync with launchpad...last I heard we were waiting on some answers from your team.

Hi Dag! I wonder if Launchpad

Hi Dag!

I wonder if Launchpad could do something like this:

When it first starts getting reports on a package, send mail to the upstream maintainer, telling them that downstream bugs in their package are being tracked here, and that they can subscribe, or use the web or rss interface, to be notified when there are changes to these bugs. This should be only once (or eg once/year), with an option to silence it.

I would guess Launchpad either has or could guess an upstream maintainer address from the packaging data, or it could ask people to find and enter one.

Hi Martin, This is fine by

Hi Martin,

This is fine by me. Although not in all cases the upstream contact is a single individual. In some cases I can imagine upstream to be the mailinglist itself.

Other projects have other requirements regarding how and when to be contacted. But at least notifying some of the people that are listed on the website or in the distribution of the sourcecode seems a worthwhile thing to do.

I was glad that Debian started to store the official project website as part of the package metadata. But one or more contact email addresses probably belongs in the metadata as well.

And in fact, what is missing too is the communication in the other direction. As a packager I am seldom informed of new upstream releases. What I ask from people is to report new release on freshmeat (where I subscribe to the project's records) but about 15% of the projects do not announce new releases on freshmeat.

I am sure that if Launchpad would interface with Freshmeat to use it as a means to get to new releases to inform their packagers, that more upstream projects would use freshmeat as a single location to report new releases. To the benefit of all projects.

(And if Launchpad is used as the upstream's tool for managing releases, Launchpad could help in announcing new releases on freshmeat as well !)

Debian automated?

Uhhh, Debian's bug forwarding is in no way automated. We rely on maintainers and people caring about the packages they use/maintain. Personally I try to forward all patches/bugs upstream where I can and drum it into new folks that working upstream is the right way to go.

It may not be automated in

It may not be automated in the real sense of the word, but it is part of the process/workflow. Since I got notified for all my Debian packages and knew exactly what I could expect and subscribe to.

And in my opinion we could improve it to be liked that for all distributions by default.

Barrier to entry

Another way in which the Debian bug tracker is a better service to its users: One can submit and follow bug reports just by using email.

This makes it far simpler to begin using the system: just report a bug from your existing email account, and the system then knows everything it needs to know about you to keep working on an ongoing basis.

Significantly, with the Debian bug tracker, one does *not* need to set up and maintain yet another useless website identity just to interact (however infrequently) with the bug tracking system.

Sadly that barrier is still there for Launchpad, Bugzilla, RT, and many other bug tracking systems. That, to me, is a big gap in ease of use.

subscribing to Fedora package bugreports

You should be able to watch dstat bugzilla activity (and more) using the packagedb interface at:


A fedora account is required, though.

It is not just bugtracking...

It has been considered best practice in Debian since forever to contact upstream and build a working relationship for as long as you remain packaging their software. That includes subscribing to upstream mailing lists, tracking and working on upstream bugs as well, etc.

However, as one would expect, many maintainers don't do it even in Debian, let alone on Ubuntu. Too many people like quantity over quality, or maintain stuff they are minimally interested on (maybe it is a dependency lib, etc).

And you WILL notice I am not talking about automated tools or any such stuff, here. If you are downstream for some software package, and your upstream doesn't know you by name, something is not right.

When the first contact is not good, the downstream maintainer is likely to just ignore upstream from now on and act as a pure "consumer" of new releases. Which is not good for either side...

don't give up on Launchpad

Hi Dag, i strongly believe that launchpad is a step forward to what you're describing. With the API and plugins that are being developed the work between upstream and distros and between distros itself could be really helpful.

There's a fair amount of work to do, into Launchpad itself, into different Bugtrackers and into the Bug Tracking process at Launchpad.

what i'd suggest is whenever you've got the time come to #ubuntu-bugs at freenode. there are a lot of people there whom can talk with you about how we can improve the relationships between your projects and launchpad and the people around it.

I did a quick look into launchpad and i've found that you missed dconf for bug mail registration (https://edge.launchpad.net/ubuntu/+source/dconf)

The others corresponding projects i've found (unoconv,dstat) already had you as bugmail contact. Don't know if there's some other project?

Anyway great post!! and i'm a big fan -and user- of your great work!!


Re: Barrier to entry

bignose, Launchpad has an email interface. Maybe you'll need to register on the web first, but then you can do everything per mail.

That said, I definitely prefer browsing the bug reports on LP than to dig through my Debian bug mail account. Everything in one page vs all kinds of mails with different subjects - you definitely need a well-customized mail client to use the BTS efficiently. And I like it better when people post small comments and attach things rather than mailing long quotes and inline attachments. The Debian BTS is only usable because so few people participate in a typical Debian bug report. With the activity and crowds you sometime see in Ubuntu bug reports, the BTS would be hard to use IMO.

And re "yet another useless website identity" there is OpenID that helps.