Reporting bugs upstream

I checked out Joseph Schmidt’s blog post on reporting bugs upstream and I thought I would respond to clear some things up and explain how we do things around here in Ubuntu land.

Josephs starts off with “I am not trying in any way to pick on Ubuntu. They are just keeping statistics in a way I can put some numbers behind my rant.” Heh, ok, fair enough. However, we do have an Upstream Report where we do break this down by package. This is way more useful to study than the page of ~800 or so pile of bugs.

It would be easy to point at a big pile of bugs and come to conclusions. But let’s look at some of these bugs. Some of these are old, they might be fixed in ubuntu but not in another component; I see a bunch that can be resolved (they’re stale and rotting), I see a bunch that just aren’t very good bugs to begin with. Still, it’s a pile of bugs that need to be fixed or resolved.

However, it’s not just about numbers, it’s about quality and context. If today we told all the bugsquad members to automatically forward every Banshee bug we get to upstream we would overwhelm them with badly reported bugs and actually hurt the project. What we strive to do is to act as a good filter for upstreams so that when they get a forwarded bug report from one of our triagers they get the information they need to fix the bug. Doing this with consistency across an entire project is hard which is why we are always doing training classes during openweek and hug days, targetting upstreaming bugs during hug days, and we even have a page that I trudge through nearly every day where people are leaving links in comments but not linking. I usually send them a mail explaining how to link bugs.

This last week we had a Hug Day with the Empathy folk. Look at that list of bugs, those aren’t a pile, those are a specific targeted set of bugs in context with the hug day – we want to be efficient and get the most bang for the buck, that means looking at “the pile” and prioritizing and figuring out which ones upstream wants to see the most. How do we know which ones upstream wants? Having a QA relationship with the upstream is a great start. In this case we have a wonderful upstream who works with our desktop team to make this work. This is a great example of teamwork, we have many others. We also have some poor ones I am sure. (And if you are an upstream who feels we suck at this, let me know immediately)

What else are we doing? As it turns out, many incoming bugs tend to be of poor quality. It’s not the person’s fault, a good bug report is an acquired skill that needs practice! We have a great tool called Apport that fires off when an app crashes. It has the capabilities to gather information from the user and stick it in a bug report. It’s handy. We want more people to use it because it cuts down on the mundane bug ping-pong discussion. “What version, what distro?” etc. We are making an even more concerted effort to increase apport usage among our users so that the bugs coming in start off being better. When I ask upstreams what they think of apport crashers bugs forwarded to them the result is usually very positive.

Please remember that we are very, very sensitive to turning on something that will autospam an upstream bugtracker, and in my opinion, rightfully so. Forwarding bugs to upstream isn’t fixed with a shotgun, it’s fixed with a scalpel. It takes time to go through those and make sure the right ones get forwarded. We have two guys in Ubuntu that are really good at this, they’re the top 2 reporters of bugs for GNOME last year. This is the kind of activity we want to see across the board and doing this properly is very important to Ubuntu and Canonical – if you’re an upstream and you feel like we can improve in this area, please get a hold of me.