This page describes how to help the GNOME team by doing bug triage.

What you need

How to help

First of all, pick a package you want to work on. Not all packages need the same amount of attention. High numbers in the Popcon column generally indicate it is part of the default installation. Similarly, packages with higher number of bugs will take more time to handle.

To avoid having two people working on the same package at the same time, it is best to indicate that it is being worked on in the IRC channel’s topic. If there are a lot of people working simultaneously, this page will also indicate which packages have been done.

Once you have chosen a package and reserved it, you can start going through the list of bugs. Start with higher severities - following the order in which they appear in the BTS is generally wise.

What to do with a bug

These are general guidelines for dealing with bugs on GNOME packages. Before them, you need to apply common sense. And when in doubt, just ask - IRC is here for that.

Although the document is long, after some start-up heating time, you should be able to deal with 5-10 bugs per hour.

Some bugs are not bugs

A subset of reported bugs are simply here because the user did not understand how to do something. This often happens when the way to do something has changed in a new version.

Similarly some feature requests are simply not reasonable. For example a request that implies to add new configuration elements for a very specific use case will be rejected by upstream. Knowing it, you can save a lot of time.

Some bugs are not for GNOME

Some obvious cases are never bugs in GNOME packages, even if they can be triggered by them:

And of course, each package has its lot of lower-level layers it interacts with, and which can also show bugs. Typical cases are totem with GStreamer, and evince with poppler. Sometimes the bug obviously belongs to the lower layer; sometimes it does not, in which case you can ask the user for confirmation by making him try another package that uses the same plumbing.

Fix severities

It is very often that bugs are reported either with an inflated (OMGWTFBBQ this doesn’t work) or too low (severity? what’s that?) severity. Don’t forget the general guidelines:

Look for duplicates

After going through the list of bugs and fixing the severities, you will notice duplicates without even thinking of it. You can merge them, but only after checking they are more than just similar.

Similarly, beware of people who report several issues in the same bug, or people reporting new bugs to an existing one just because it looks similar. The clone command of the BTS can help you in these cases.

Bugs that are already forwarded

Some bugs are already marked as forwarded. In this case, some usertags are automatically updated to match the upstream bug. To see them, add the following string at the end of the bug list URL: “;

If the bug has been closed upstream, you need to check whether an update is needed.

What to do with an actual GNOME bug

So, it seems the user saw an abnormal behavior in a GNOME package. What to do now?

Are the explanations clear enough?

To do something useful with a bug, you need to understand it first. If you don’t understand what the user precisely did to see the bug, and what should have happened instead, just ask him.

Is the bug reproducible?

If the bug is of a kind that can be easily reproduced (example: click this menu entry and you get an error), just try to reproduce it with the latest upstream version.

If the bug is more specific (for example, it only happens when plugging a specific brand of USB mouse and when you dance the cha-cha around), you need to ask the reporter.

Is the backtrace complete?

In order to debug a crash, most of the time you need a full backtrace with debugging symbols. If you can reproduce the crash yourself, that’s generally easy, but otherwise you have to ask the reporter to install the necessary detached debugging symbols. Sometimes, this is not enough and you also need to install an unstripped version of the package.

More information: HowToGetABacktrace

Is the bug assigned to the correct package?

Generally, bugs reported against a metapackage belong in one of the dependencies. And often, bugs reported against a specific package actually belong to another one – either a lower-level layer, or another package which became responsible for the same functionality in a newer version.

For crashers, the full backtrace will generally tell in which package the error belongs to. Beware: it’s not always the library in the last call before the crash.

What to do with a valid bug in the correct package

“Yes, everything is OK, so what to I actually do?”

Debian or upstream?

You need to check whether the bug comes from Debian or also exists upstream.

Packaging bugs

These are the easiest ones to fix, and also the ones which will improve your Debian skills. For these ones, propose an approach and/or a patch, and get it committed on the repository.

Once it is committed, tag the bug pending.

Bugs in patches

The easiest thing to do with a bug in a patch is to drop the patch. However, patches are generally here for a reason, so this has to be a trade-off between the benefits and the newly found bug. Of course, often you can get simply fix the patch. In this case, don’t forget to send the new version upstream. If you don’t know how, look in the changelog for the person who introduced that patch and ask her to fix her mess. If the patch is forwarded (it should be indicated in the patch header), you can indicate in the corresponding report which side effects it has.

What to do with an upstream bug

Otherwise, the bug comes from upstream. Once you have it as such, you should first check whether they are already aware of it.

Looking for already reported bugs

Most crashers should already be known upstream. For other reports, it really depends.

Use the search function of the GNOME bugzilla to look for existing similar reports.

You should also check whether the bug has already been fixed in the upstream git repository. Therefore, you can have a look at the master branch for related issues that could have been fixed. For crashers, look at the files that appear in the backtrace. For other bugs, search in the commit logs.

Forwarding a bug

If the bug already exists, you just need to add a comment to it, pointing to the Debian bug.

If it doesn’t, you need to open one with the bugzilla web interface. The fields should be self-explanatory, and copy-pasting the original report is often enough, but don’t forget to mention:

In both cases, don’t forget to mark the Debian bug as forwarded. It is very important so that bts-link can track the status of the bug.

Fixing a bug

Even if you are not able to write a patch yourself, sometimes you will find a patch:

It is not always interesting to include such a patch, and it depends on several factors:

If it is worth the deal, commit it to the subversion repository or ask on IRC for someone to commit it.

Bug triage week-end - 27-28 february 2010

These packages have been done: