Bugzilla/Bug report guide

This article should address many things you should keep in mind to make other people's life easier, when filing a bug report. Always remember, that they care about your problems for free.

Creating a new bug
Search for duplicates. Maybe someone else reported your problem, too? If there are no duplicates, create a new bug.

Adding information to another bug
Always stay on topic. A bug tracker is used for technical reports and chitchat should be avoided. Keep them in the forums, irc or mailing-lists. Only confirm the existence of a problem once. It does not help solving the problem, if you and another person report it twice. But if your and the confirmer's systems differ in an obvious way and that would be helpful to know, add this information. Do not hijack other bugs. If your problem is not discussed on a bug, search for one related to your issue or create a new report. No talk on tracker bugs. Those bugs are meta bugs. If you want to add useful information, add them to a related sub bug or create a new bug.

Packages/ebuild
You should always add information about your system configuration to the bug. To do so, create a new attachment and paste the contents of:

Package XY was released in new version
First: Calm down. So called zero-day requests (that means the bug report happened not later than 24 hours of the release announcement) should be avoided.

Package XY should be marked stable

 * Did you test the version you want to become stable thoroughly?
 * Are there other bug reports regarding this bug?
 * Was the version of the package added to the tree at least 30 days ago?
 * Are its dependencies all marked stable?

Kernel
Files and information of interest for kernel bug reports ordered by priority:
 * which kernel and version is used on what architecture e.g. gentoo-sources-3.4.2-r2 on x86_64
 * the kernel config file should be attached to the bug report
 * a list of all devices in the system can be aquired with lspci -k
 * log files during kernel intialization should be attached or