GNOME/Bugs

From openSUSE

Summary for the impatient:

This page describes the bug triaging policy for the GNOME Desktop part of openSUSE. It includes desktop-ish things like OpenOffice.org and Firefox. The idea is to have a simple way of categorizing bugs that will help us know which bugs to fix first.

We describe some bug categories which we put in the "Status Whiteboard" field in Bugzilla. We can then use certain bug queries to look for bugs easily.

This page is not for these:

• To list your favorite bugs. Please see our bug policy. Once you know the right categories for your bug, please add them to the Status Whiteboard field in Bugzilla.
• To propose packaging some software that is not available for openSUSE yet. To do that, please go to the Wishlist_Gnome page.

Bug lists

Bugs by category

See "introduction to bug categories" for an explanation of what the categories mean.

Bugs are being categorized one by one. You can see the instructions to add tags to bugs.

Generic bug lists

Bugs by severity. Severity is the typical way on Bugzilla to set the importance of the bugs, and it is usually changed depending, first, on the kind of bug, and second, on the number of people affected by it.

• Upstream GNOME 2.19.x/2.20.x bugs sorted by severity
• Bugs with the most duplicates - FIXME: need to filter this to show only openSUSE bugs.

Bugs by number of votes. People can use the voting feature on Novell's bugzilla to get attention on the bugs they want fixed. You can read extra information about voting in Bugzilla.

• openSUSE 11.0 and 11.1 bugs sorted by number of votes
  • openSUSE 11.0 bugs sorted by number of votes
  • openSUSE 11.1 bugs sorted by number of votes
• openSUSE 10.2 and 10.3 bugs sorted by number of votes
  • openSUSE 10.2 bugs sorted by number of votes
  • openSUSE 10.3 bugs sorted by number of votes
• openSUSE bugs with at least 1 vote
• openSUSE bugs with at least 10 votes
• openSUSE bugs with at least 20 votes
• openSUSE bugs with at least 30 votes

Bugs that do not get attention for a long time.

• openSUSE bugs with no activity for more than 30 days
• openSUSE <= 10.1 bugs still open

Bug topics and tracker bugs

• GNOME/Multiscreen bugs - Bug #374148- for people who have more than one physical monitor.
• Bug #338002 - Tracker bug for fonts, DPI issues, and GNOME/KDE font interop.
• Bug #338003 - Tracker bug for GtkFileChooser issues.
• Bug #341831 - Tracker bug for gnome-main-menu - behavior bugs ( Main menu bug week)
• Bug #349357 - Tracker bug for gnome-main-menu - performance bugs
• Bug #341832 - Tracker bug for beagle.
• Bug #381401 - Tracker bug for GNOME-related printing issues.

Suggested topics: "all bugs around creating documents", "all bugs around file management", "all bugs around CD burning", "GUI quirks". Please start a new wiki page if you intend to collect bugs under a new topic.

Policy for bug triaging

Introduction to bug categories

Triaging is the process they use in hospital emergency rooms and war zones to decide which patients to attend first. In our own little war zone (the openSUSE distro), triaging means organizing new bug reports so that we can decide which of them to fix first.

Let's look at a way to classify bugs depending on whether they actually prevent you from getting work done. These go from high priority to low priority:

Showstoppers. GDM doesn't let you log in. Or the screensaver can't be unlocked. Or your whole session crashes at random times and you get back to the login screen. These are obviously of super-high priority to fix, because you cannot get anything done while the bugs are present. The category for these bugs is gnome-showstopper.

Functions you use that do not actually work. You are using openSUSE and ask a program to do something, but it doesn't work. For example, you hit "File/Print" but it doesn't do anything, or prints garbage. This is a big problem, since you cannot accomplish your work while the bug is present. The category for these bugs is gnome-function-does-not-work.

Things that are wrong out of the box. You are using openSUSE and casually find something wrong. For example, the file manager displays your hard drive's free space incorrectly, or you can't read all the text in a window unless you make it bigger. You say, "stupid software", but you can still keep on doing your work. The category for these bugs is gnome-wrong-out-of-the-box.

Accessibility. We care about making our software usable for people with physical disabilities or with reduced hearing, vision, or motion. For example, an operation that can only be performed with drag-and-drop cannot be used by people who cannot use a mouse; or a program which does not let you change the font size will be hard to use for people with impaired vision. Therefore, we have a special category for problems which prevent people with particular disabilities from using our software adequately. The category for these bugs is gnome-accessibility.

Everything else. Enhancements, minor usability problems, cosmetic fixes, etc. These by definition don't prevent you from doing your work, but would be nice to have. Sometimes we can mark these bugs "to be fixed upstream", i.e. so that the GNOME community-at-large can look into these problems.

(Security. openSUSE already has a well-defined process to deal with security bugs (FIXME: link to this process), so we will not consider security bugs here.)

When processing a new bug, you should add the relevant bug categories in the "Status Whiteboard" field, especially the gnomeup-$module categories.

Special categories:

• gnome-usability - For problems which make the software hard to use.

• gnome-crash - Crashes are a particularly violent kind of bug, so it is useful to tag them specially, in addition to the usual gnome-showstopper, gnome-function-does-not-work, or gnome-wrong-out-of-the-box categories.

• gnome-performance - Bugs that affect seriously the performance of our applications.

Bugs in old versions of openSUSE

We cannot expect everyone to install the newest openSUSE as soon as it is released; people will keep using older products for some time. But when people actually upgrade, they expect many problems to have been fixed. So, we must pay special attention to bugs which are persistent across releases.

Persistent bugs. You reported a bug for openSUSE 10.2, but when you upgrade to 10.3 you see that the bug still exists. If the bug is of the kind "things that are wrong out of the box" as described above, you will think, "this sucky distro has no quality control". Or worse, if the bug is of the kind "functions you use that do not actually work", you will think, "this distro is written by idiots and really has no quality control".

When a new version of openSUSE is released, we need to go through all the old bugs to try to replicate them in the new version. FIXME: how much help can we get to try to replicate the bugs in both the old and in the new distros? Can we schedule time from the QA team for this? If a bug is hard to replicate in the old distro and obviously is not present in the new distro, then it is not worth investigating anymore.

Tagging old bugs which still happen in new versions

Let's say you have a bug for openSUSE 10.2, but you noticed that the bug still appears in 10.3. In that case, do this:

1. Find the Impact box in the Bugzilla bug. Change the OS drop-down to "openSUSE 10.2". This lets us know the distro where the bug was initially created.
2. Change the Product of the bug to "openSUSE 10.3". Thislets us know that the bug still happens in the new distro.

Backporting fixes

If a bug is fixed in a newer version of openSUSE, and if the bug also exists in an older version, we can try to see if it is easy to backport the fix. To avoid pointless maintenance, we can do this only for "showstoppers" and for "functions you use that don't actually work".

Easy backports. Maybe the code didn't change very much and backporting the fix takes just a few hours; it is definitely desirable to "support" old products like this.

Hard backports. When the code changed a lot, or when the fix is easy but requires a large new piece of infrastructure. These backports are to be avoided, unless there is a lot of interest (a very frequently-used function that doesn't work, a very highly-voted bug). In any case, not backporting these would give people an incentive to upgrade to the latest openSUSE.

In a newly released stable version, there might be multiple bugs in one package that we might want to see fixed in online updates. If those bugs are not urgent, it's possible to tag them with the gnome-update tag so that we only release one online update with all the fixes.

Dealing with new versions

The latest stable distribution will get most of the bug fixing effort, except when a new distribution's alpha versions become available.

For example, as of October 2007, openSUSE 10.3 is the latest stable version, so most of the bug fixing effort will go into it. Some months later, when alpha versions of openSUSE 11.0 start becoming available, we will focus instead on that. All along the way, we will try to handle important bugs in 10.2 if time allows.

Fixing bugs

These are the most important bugs to fix, in order:

1. gnome-showstopper - Since nothing works while these bugs are present.
2. gnome-function-does-not-work - Since these bugs keep you from getting work done effectively.
3. gnome-wrong-out-of-the-box - Since they make the software look bad and unpolished.

Apart from these basic criteria, we can have "bug days" or "bug weeks" where we fix bugs within one particular topic; see the next section.

Sometimes, the GNOME/Team GNOME team will not make an accurate assessment of a bug's severity. For these situations, we will use the voting feature in Bugzilla, where people can vote for which bugs they would prefer to see fixed first. We can then adjust the severity and/or priority of bugs based on their number of votes, to make the bugs easier to see in the bug lists.

"No showstopper" policy

Starting with openSUSE 11.0, we will have a "no showstopper" policy. This means that no bugs with the gnome-showstopper tag will be allowed into the final distribution.

Since wishing for things to happen does not actually make them happen; we look forward to people helping out to fix these bad bugs! :)

Practical information

How to classify bugs

1. Load the list of bugs in Bugzilla.
2. Sort the list by Bug ID.
3. Look at the bug that follows the bug mentioned above.
4. Categorize the bug by putting the bug categories in the "Status Whiteboard" field in Bugzilla.
5. Update the bug number in this page and the date!

Categories which you can cut&paste into the Status Whiteboard field

 gnome-showstopper
 gnome-function-does-not-work
 gnome-wrong-out-of-the-box
 gnome-crash
 gnome-usability
 gnome-accessibility
 gnome-performance

To identify the relevant upstream modules for each bug, you can use gnomeup-$module categories.

 gnomeup-$module

For example, a nautilus bug should use gnomeup-nautilus and a gnome-control-center bug should use gnomeup-gnome-control-center. Note that there's already a "banshee" category for banshee bugs, so don't use gnomeup-banshee.

And for bugs which we can't fix ourselves (generally due to lack of resources), or for bugs which we fixed and whose patches need to be sent upstream:

 should_go_upstream

Future work

It would be useful to get trends on how many bugs get opened/closed for each component, and upstream too; we can use Bugzilla's charts feature for this.

Ideas for how to deal with other bug trackers

Have an RSS feed of bugzilla queries in other bug trackers.

Modify Bugzilla to allow referencing bugs in other bug trackers (is this in newer versions of Bugzilla?).

Missing infrastructure

• In Bugzilla, one should be able to specify that a bug occurs in certain versions of the product. Have a bunch of checkboxes:

Bug 12345 - The Foo command doesn't work in BarApp
  [ ] openSUSE 10.2
  [x] openSUSE 10.3
  [x] openSUSE 11.0

Bugzilla would also need an easy way to look for bugs that appear in more than one version of the product.

• Bugzilla should be able to link to other Bugzillas ("this is bug xyz in bugzilla.redhat.com") and monitor their status there. Bugzilla should send out notifications when the status of those remote bugs changes.