Bugs and feature requests

Bugzilla is the tracking tool used by the Fedora Project to get feedback from users and developers on bugs and requests for enhancements in Fedora.

Sometimes, new reports are missing information, are inaccurate, or have other flaws. This wastes valuable time. The person who reported the bug wastes their time when they file inaccurately, and the developers have to spend more time on the bug, which wastes their time, and may even result in the bug being ignored or forgotten. This page describes how to file quality bug reports and suggest enhancements in a constructive manner.

The Fedora common bugs page is useful for finding fixes to already known issues.

Notes

• The Fedora Project has the objective to be a platform built exclusively from free and open-source software. Suggestions to include support for proprietary or other legally encumbered software is not constructive. See the ForbiddenItems page for details about this.

• If a particular software package is heavily used, it is more likely that users will find bugs and/or suggest enhancements to it. It does not mean that the software is more buggy.

• Developers do not normally acknowledge bug reports or offer comments unless they have substantial feedback or require more information from you. It does not mean that your bug reports have not been valuable. Keep them coming!

• The Fedora Bug Triaging team is actively soliciting new volunteers.If you are interested, Please see the BugZappers page.

• Bugzilla only lists source packages. If for example, you need to file a bug report against mount, you can find the source package by using the following command.

rpm -q --qf "%{SOURCERPM}\n" -f /bin/mount

Output:

util-linux-2.13-0.10.pre5.src.rpm

Getting Started

• If you are new to Fedora's Bugzilla, then the first step is to register an account. It's a quick process, so don't hesitate to get started right away. For details about the account creation process, please consult the bugzilla documentation.

• When reporting a bug, it is helpful if you select the right Product, Version and Components. By doing so, you reach the developer/maintainer of the affected software package, which helps resolve the bugs faster. If you assign it to the wrong component, it can be reassigned to the correct one, so never skip filing a bug report just because you couldn't figure out which component to assign it to.

• More guidelines to get started at http://www.redhat.com/magazine/020jun06/features/bugzilla/

User Etiquette

• https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Understanding the Status and Resolution

After reporting a bug, you might get feedback from other users, or the developer may change the status and/or resolution of the bug report. For an explanation:

https://bugzilla.redhat.com/bugzilla/page.cgi?id=fields.html#bug_status

Reporting Bugs

• http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Enhancement Requests

• When filing it, add keyword FutureFeature to the report. Make sure you supply enough information and rationale for your enhancement requests to be considered.
• If you want to make a new feature happen on your own create a wiki page for your feature and get it accepted. See more on the Feature Process at Features/Policy.

Security

We pay special attention to security-related bugs. Read the Security Bugs page to understand the special process.

Crashes

If you have experienced a program crash, it will almost certainly be necessary to include a stack trace with your bug report. Crashes are often difficult to reproduce and even more difficult to fix, so the more information you can provide, the better. You will probably need to install -debuginfo RPMs so your stack trace will have useful debugging symbols. See the following pages for more information:

• StackTraces
• JavaStackTraces

Anaconda Installer

If you are reporting bugs with the Fedora Anaconda installer refer to Anaconda/BugReporting for details.

Kernel

See the kernel triage page for information on debugging and reporting kernel bugs.

Virtualization

See the Tools/Virtualization/BugReporting page from tips on reporting virt bugs.

Xorg

Information on debugging Xorg in Fedora is available from the Xorg Debugging page.

OpenOffice.org (OOo)

OOo is quite big, and it links to and uses a lot of stuff, and so brings up a lot of problems that are not always OOo bugs, so...

• A crash on startup might be a crash in some OpenGL lib, not OOo itself.
• Get the test source at [1] .
• Run gcc testgl.c -o testgl -lX11 -lGL to compile it.
• If it also crashes, your bug is probably not an OOo bug.

• Check that similar applications don't behave the same way, e.g. if Firefox/gedit/glxgears do the same thing as OOo, then it's unlikely to be an OOo bug.

• If the crash dialog appears, paste the stacktrace it gives you into your bug report.

• Mention if you are using KDE or GNOME, as it often matters. If you have non-Fedora-supplied KDE theme engines installed, try one of the supported ones.

• If there is an error/warning message, say what the message is.

• If it happens with a particular document, attach the document. If you can, trim the document down to the smallest test case that reproduces the problem. "Scroll to page 912 and the graphic is misplaced" is much less appealing than having a one-page example.

• If you think there is something wrong with what is being displayed, attach a screenshot. I might not understand your description.

Example: "formula font is wrong"

Is it the font used in the text area for editing the formula, or is it the font used to display the formula? Did you mean the math editor, or did you actually mean formulas in calc? A screenshot would solve these kinds of questions.

• Try not to tag things onto bugs with "and this unrelated thing doesn't work" or "yeah that fixed it, but something different is still not the way I want it" -- mutating bugs are really difficult to deal with. There's no problem with opening multiple bugs, and it's easier to merge bugs together if they turn out to be the same thing than to unmunge them into separate bugs.

• If you know you have something unusual about your setup, mention it.

Examples:

• ".doc documents created with msword running under wine don't open in OOo" as opposed to just saying ".doc files don't open in OOo"
• "Saving to a samba share doesn't work" versus "saving doesn't work"

• If you can, install the debuginfo and try:

$> gdb /usr/lib/openoffice.org/program/soffice.bin
(gdb) run -writer
(gdb) bt

Paste the backtrace in your bug report.

(-writer should be changed accordingly: -calc -impress -math -draw)

• It's nice when someone finds that a bug was resolved in an update and mentions it in an old, unclosed bug, but it is not so useful when someone adds an unprompted note to say that the problem is still there.

• "This is unacceptable" is not good motivational practice.

References

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html