This page describes how to help the GNOME team by doing bug triage.
Contents
What you need
First of all you need an up-to-date unstable (sid) Debian system. If you don’t want to install unstable on your desktop computer, you will need either of:
- a chroot with unstable packages installed;
a virtual machine (I recommend using qemu-kvm or virtualbox-ose);
- a dual boot system.
You need a GNOME Gitlab account; click here if you don’t have one yet.
You need an IRC client connected to #debian-gnome on the OFTC network.
Having read the BugTriage page is a plus.
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.
- If the feature is obvious enough, or correctly documented, just point the user to it and close the bug.
If the documentation is lacking, make the bug minor and retitle it to point it is a bug in the documentation, then treat it as such.
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:
- If the computer crashes or dead-locks (no SSH access), this is a bug in the kernel; you need to gather the kernel version of the user and reassign the bug to linux-2.6. If she uses a custom kernel, you need to tell her to try the Debian one first.
If the X session crashes, going back to GDM, this is, except for some rare cases of crashes of the D-Bus daemon or the session manager, a bug in the X server. Ask the user for the brand of graphics card and the driver she is using. In more than half the cases, it is caused by the proprietary nvidia driver (nvidia-glx). Otherwise, reassign to xserver-xorg-video-driver.
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:
- Critical bugs are for packages that break the whole system, not for those that break a specific usage or a specific user.
- Crashers are either grave (happen all the time) or important (happen in specific conditions).
- Serious bugs are for policy issues; most of the time, they come from packaging errors (e.g. missing dependencies).
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: “;users=bts-link-upstream@lists.alioth.debian.org”
If the bug has been closed upstream, you need to check whether an update is needed.
- If a fix has been committed, have a look at the corresponding commit. If it is already in unstable, you can close the bug with the appropriate version. If not, you can go to the “Fixing a bug” section.
- If the bug has been marked as INVALID or NOTABUG, you should check why, but this often means the Debian bug can be closed too.
- If the bug has been marked as NOTGNOME, this generally means it is either a packaging bug, or a bug in another package.
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 it it still here, you can get ready to forward and/or fix it.
- If it is not, just close the bug with the version that you think fixed it (the current version if you don’t know which one).
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.
- If the bug is already old (more than one major GNOME version was released), just ask if it is still here.
- If the bug is recent enough, have a look at the changelog.gz in the package, to see if something related to the bug has changed in the meantime.
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.
- Dependency errors, or things related to the set of installed packages, are most of the time purely Debian bugs.
- Enhancements or missing features are most the time purely upstream bugs.
- Common errors in packaging include: missing or wrong configure switches, files not installed at the correct place, or buggy patches that we stole from the wrong place (because of course, patches we write ourselves are never buggy).
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 GitLab to look for existing similar reports.
Most of the time, you will need the following syntax: product:package-name keyword
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 GitLab Issues. Just select the project for which you want to create an issue for and the fields should be self-explanatory, and copy-pasting the original report is often enough, but don’t forget to mention:
- that you are not the original reporter of the bug,
- whether you could reproduce the bug yourself or not,
- the URL to the Debian bug report.
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:
- in the Debian bug report;
- in the upstream bug report;
- already committed in the upstream git repository;
- in another distribution’s bug tracking system, from a link found in the upstream report.
It is not always interesting to include such a patch, and it depends on several factors:
- the length and complexity of the patch,
- the severity of the bug,
- the possible side effects,
- who wrote the patch.
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:
- accerciser (joss)
- alacarte (joss)
- zenity (pochu)
- epiphany-extensions-more (agx)
- gcalctool (dktrkranz)
- gnome-python (dktrkranz)
- devhelp (pochu)
- anjuta (joss)
- at-spi (joss)
- brasero (joss)
- bug-buddy (joss)
- dasher (joss)
- meta-gnome2 (pochu)