(The following is taken from the FAQ.)

Bugs should be reported to the GNOME bug tracking system (http://bugzilla.gnome.org). You will need to enter your email address and receive a password before you can use the system to register a new bug report.

There are a number of options to select and boxes to fill in when submitting a bug report. Please remember that the more information you give, the easier it will be to track the problem down. Extra information that may prove useful includes:

How to reproduce the bug.

If you can reproduce it with the testgtk program that is built in the gtk/ subdirectory, that will be most convenient. Otherwise, please include a short test program that exhibits the behavior. As a last resort, you can also provide a pointer to a larger piece of software that can be downloaded.

(Bugs that can be reproduced within the GIMP are almost as good as bugs that can be reproduced in testgtk. If you are reporting a bug found with the GIMP, please include the version number of the GIMP you are using)

If the bug was a crash, the exact text that was printed out when the crash occurred.

Further information such as stack traces may be useful, but are not necessary.

If you do send a stack trace, and the error is an X error, it will be more useful if the stacktrace is produced running the test program with the --sync command line option.

This information below is mostly useful for people who try to work on the bugs in Bugzilla.

Component

We are moving towards more fine-grained components, to make the large number of open bugs more manageable. Some of the more complex widgets have their own component now, others are grouped together, e.g. the "combobox" component is used for bugs related to GtkCombo, GtkOptionMenu, GtkEntryCompletion and GtkComboBox.

State

We do not use the UNCONFIRMED state, bugs in the UNCONFIRMED and NEW states are treated the same. Bugs will generally stay in the NEW state until they are either resolved in some way or moved to the NEEDINFO state. The NEEDINFO state indicates that additional information from the bug reporter is needed. The bug reporter is expected to reopen the bug if he provides the requested information. We occasionally close bugs which have been in the NEEDINFO state for a long time (at least 6 months) without any response from the bug reporter.

Priority and Severity

We generally don't pay much attention to these fields, except for the use of the Priority field to denote "must fix" bugs for a certain release.

Milestones

An unmilestoned bug has not been looked at in depth yet. Milestones of GTK+ bugs generally indicate the next version in which the bug can be fixed - there is no guarantee that the bug will be fixed in that version. We use the priority field to distinguish "must fix" bugs for a version. Bugs with milestone x.y.z and priority High are the ones which we consider "must fix" bugs for release x.y.z.

Starting with the 2.8 development cycle, we will try a new approach to milestones that is closer to how we work with bugs and will hopefully let us avoid moving an ever-growing mountain of bugs from milestone to milestone.

We keep the idea of the 3 "current work" milestones,

• 2.6.x

• 2.8 API Freeze

• 2.8 Freeze

but bugs will only go onto one of these milestones if one of the following criteria is met:
• We couldn't ship the milestone without fixing it
• Someone has signed up to fix the bug before that milestone
All other bugs are assigned to a set of "pool milestones". These are groups of bugs that are intended to help people figure out what bugs they should sign up to fix for a milestone.

Here is a list of our current pool milestones:

Need diagnosis

A reported bug that the maintainers of GTK+ can't commit to fixing because they don't know what is going: there are no reproduction instructions or it occurs on a platform that they don't have acess to. This is different from NEEDINFO because NEEDINFO should mean that the bug is waiting for specific information from the reporter.

Small fix

A small bug with a diagnosis that needs code written to fix the bug (few minutes to a few hours)

Medium fix

A reported bug with a diagnosis that needs code written to fix the bug (few hours to a week)

Small feature

Small feature additions; no new API (few minutes to a few hours)

Medium feature

Medium feature additions; no new API (few hours to a week)

Big feature

Big feature additions; no new API (1 week to 1 year)

Small API

Small API additions (few minutes to a few hours)

Medium API

Medium API additions (few hours to a week)

Big API

Big API additions (1 week to 1 year)

Keywords

A number of keywords are used regularly with GTK+ bugs, none of them are used 100% consistently. The more common ones are:

• PATCH a possible patch is attached to the bug. Note that not all bugs with attached patches automatically get this keyword. If a patch is found unsuitable for some reason, the PATCH keyword is removed. The PATCH keyword is no longer needed today, since Bugzilla can query for bugs with patches now.

• easy-fix marks bugs which are considered relatively straightforward to fix, so that volunteers have a good chance of producing an acceptable fix.

• PATCH_NEEDED indicates that we need help with this because either we don't care enough to fix it ourselves, or it's something we have no clue about.

• API bug involves API changes.

• string bug involves string changes.

• keynav bug has something to do with keyboard navigation.

• accessibility issues like widgets which fail to implement accessibility interfaces.

• portability issues like build failures on certain platforms.

• multihead marks bugs having to do with the support for multiple screens/displays.