Report Information

The options which show up here vary according to which of the radio-button choices you make. Sometimes it is much more helpful to add information to an existing report than to start a new one. (And sometimes you realise you forgot something in one of your earlier reports, and you want to add it. You can search the bug trackers for GNOME, KDE or Debian to find a relevant bug report and note down the number. If you then select Add information to an existing bug report, you will be prompted for the bug number to add to.

If you select File a new bug report then you will be prompted for the package number, the package version, the bug severity and the class of bug:

Package

You can search through the drop-down list for the correct package to assign this bug to. If you know the exact filename of the program you ran, and you use rpms, you can use the command rpm -qf /full/path/to/file to verify which package it came from. If you use Debian, you can use the command dpkg -S /full/path/to/file. To find out the full pathname to, say, gnome-terminal, or kfloppy, you can use the command which: which gnome-terminal or which kfloppy.

If you are still not sure which package to assign a bug to, searching the bug-trackers on the web by keyword to find out where other people have assigned it in the past can be very helpful.

Because there are so many possible packages, the drop-down list is split alphabetically. Clicking on a package beginning with 'a', for example, will give you a further selection of several other apps beginning with 'a'. So you will need to double-click on a package and then look at the sub-categories to find some packages.

If you do not select a package, it will be left as 'general'. This will get through to the bug-tracking system, but someone there will have to manually assign it a package, which slows its progress down. Some bug-trackers send back automatic "Please assign a package next time" responses to bugs with no package, too.

Version

Once you have decided on a package, checking its version number is much simpler. For GNOME and KDE programs, it will often be in the 'About' box of a program.

FIXME: need more about getting package version number. Debian, etc?

Severity

There are different severities of bugs you can assign. If you are not sure, normal is fine. There should not be that many critical or grave bugs in software which is in daily use. They tend to get fixed fast. So it is probably unlike you will need those two categories. Before assigning bugs to those, you really should get the latest stable version and check it has not already been fixed.

Critical

This bug makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the software. Examples would be hanging the entire machine or overwriting files it should not even touch.

Grave

This bug makes the software in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the software. A program which consistently crashes on startup or produces files called core in your home directory might well be grave.

Normal

This is what you will usually want: the default value.

Wishlist

This is a useful category for two things: very hard to fix bugs; and requests for features or enhancements. ("It would be nice if...")

Class

The default class of a bug is a software bug: "there is something wrong with the program". Sometimes this is not quite what you need. You can change the class to a few other things. A "documentation bug" is obvious. "Change request" and "support" are not. FIXME!!