Filing useful bugs at the bugtracker
Buddy your bug!
Discuss your problems with others before filing a bug report. Use the web forum, mailing list(s), or discuss it on IRC before you file a report. When filing a bug report, a link to the web forum thread, mailing list discussion or even a short abstract from an IRC conversation should be included.
This will help establish whether it is a well-known bug, a configuration issue, or an actual bug.
There are far more people reading the web forum, mailing lists and participating on IRC than there are going over bugs. This is why we urge everyone to discuss their problem before they create a ticket, not because we don't want to help you. Simply put: The chances of getting your problem solved quickly are far greater on the web forum than on the bug tracker.
What to know before you file a bug report
You can search the bug database before you file a report. Make sure you search for closed and resolved bugs, too.
- We cannot fix driver bugs, X server bugs and packaging bugs.
- We cannot work on all bugs at the same time, so you may need to wait a while before your bug receives a response.
- We aggressively close bugs, which means you might have to re-open them. This is to avoid ghost-bugs.
- Reopening a bug is perfectly OK.
Many of the "we cannot fix xyz" issues can be filed against your distribution, against X.org (http://bugs.freedesktop.org), or similar. When you are discussing the problem (which you should be doing before filing a bug), it should become obvious if and where to file a bug report.
How to fill out the bug form
Do not change the Priority or Severity fields. The developers will take care of them.
Be as precise and concise as possible. The goal is to give as much information as possible with as little text as possible. You do not have to be fluent in English.
Make sure you include which version of the component you are using, and whether you are using pre-compiled packages. The output from the package manager might be appropriate. If you are unsure about which component to choose, choose the one which you think it is likely to be, and it will get adjusted.
Include a detailed description of how to reproduce the problem, whether it is a consistent problem (happens every time, or just sometimes), and how long you've had the problem.
Be polite and respectful, and do not discuss the severity of the bug in the original bug report, why it should be fixed (it's a bug, and that should be reason enough) or how the bug should never have been there in the first place.
Information we need
Not all bugs require all of this information; if in doubt, include it anyway. If you suspect some of this information is useful but you don't know how to obtain it, ask for help on how to obtain it.
How to reproduce the issue
Where you obtained the software
Git - include the date on the version you are using.
A release - explain which, and where it was offered.
An external package repository - include its name.
The previously working version, if there was one
- Include the version number or Git date.
Which graphic card you use
- For example, ATI, nVidia, Intel.
Which video driver you use
- For example, FGLRX, NVIDIA, NOUVEAU, ATI, R300, R200, i810 (Intel Integrated), intel (New world intel driver)
Which rendering path you use
- XGL, AIGLX, or NVIDIA.
Which GNU/Linux distribution and version you use
- For example, Ubuntu 7.10 or Gentoo 2007.0
Which configuration plugin you use
GConf
INI
CCP
- Which backend (gconf, kconf, or ini).
Plugins in use
Back trace - If you're experiencing a crash, this is vital. See the crashandler plugin to obtain this.
Screenshots are always helpful for describing visual bugs.