This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Documentation Summary:

Purpose: To describe steps for reporting bugs in language comfortable to novices.

Audience: Linux users unfamiliar with bug reporting

Assumptions: The user is running Fedora linux, has access to the internet, and generally understands how to use computer software.

Related Documents: BugsAndFeatureRequests

Note: This page is intended to more beginner friendly than BugsAndFeatureRequests, and includes less technical information. Hopefully, this page won't scare away a new user as the other might.

Lead Writer: User:danielsmw

Note: You seem to be duplicating http://fedoraproject.org/wiki/BugsAndFeatureRequests - RahulSundaram

How to File a Bug Report

This page describes a procedure for reporting software bugs to Fedora developers. A bug is generally defined as "an error, flaw, mistake, failure, fault or 'undocumented feature' in a computer program that prevents it from behaving as intended" (Wikipedia). While many organizations have now adopted Bugzilla as their bug tracking system, this page focuses specifically on the use of RedHat's Bugzilla system for Fedora; however, other users may find the information helpful as well.

Reporting bugs effectively is essential for the development and refinement of Fedora's many components. Without user feedback, many bugs will lay unresolved, so learning to use the Bugzilla reporting tool can be an important end-user skill. With this in mind, remember that not everything you may use in Fedora is necessarily the responsibility of the Fedora project and its package maintainers. If you are using ForbiddenItems, for example, you should not submit a bug to the Fedora developers.

Why do we file bugs?

As a user, encountering bugs that hinder your work (or play) can often be frustrating, at best. Oftentimes, ignoring bugs and just finding a different way to get your job done makes your immediate end-user experience more efficient.

In the long run, however, failing to report bugs can cause the software you use to not live up to its full potential. This may seem like a strange concept to users coming from a proprietary software background. Bugs reported to large software corporations are influenced strongly by the market forces that sustain those companies. So, for example, if fixing a bug won't produce a net financial gain, it probably won't be fixed. Unlike these companies, programmers who develop open-source software (OSS) are free from market forces and usually develop software on their own time. As such, they take particular pride in their software and strive to see it perfected for the end-user.

What does this mean for you? It means that by properly reporting a bug, you can be sure that it will be paid attention to. It may not be fixed immediately, but the developers who create the software you use care about issues that arise and have a desire to resolve those problems. Unlike in a proprietary operating system where you might click "Send Bug Report" and never hear about it again, you should experience a result with OSS - be it resolution of the problem in an upcoming release or communication from the developers to work with you in resolving the issue. It means that filing bugs is important, and you should do it whenever you have the chance. It's just one way of giving back to the community.

Creating a Bugzilla Account

Bugzilla an open source bug tracking tool used for managing reports of issues, defects, and features by users. Bugzilla is generally operated across a web interface. To submit a bug using Bugzilla, you must first create a user account.

Point your browser to the account creation page.
Request an account using a legitimate email address.
Check your mail until you receive an account creation confirmation.
Follow the link the email to continue account creation. Fill in the requested fields, and sumbit the form.

Note that if you do not act on the email confirmation within three days, it will expire. In this case, you will need to start from the beginning again.

Once you have created an account, you can login with your email address and password.

Gathering Information

Sometimes, the most important information you can research is whether or not the bug has already been reported. When the same bug is reported several times, developers are often weighed down with having to redundantly read all of them. In the Bugzilla system, use the search feature to see if you can find an already-reported version of your bug.

Before reporting a bug, it is important to collect as much relevant information as possible. As you collect this information, make sure you at least have the following:

The name and version of the buggy software,
A qualitative description of what you were doing, and what you were trying to do, when the error occurred,
The operating system you are running, and
Your computer's architecture.

Alone, however, this information is rarely comprehensive enough for developers to resolve the reported issue. Consider reporting other information such as other running applications, any peripherals (printers, scanners, camera) that the software might have been interacting with, concurrent issues with other software (another program was malfunctioning at the same time), and the time and date at which the error occurred. The more information the developer can see, the more clues he has as to the source of the malfunction.

Finding Common Information

Your bug report will almost always contain the information listed above, although more often than not additional information will be needed. Nonetheless, it is good to know ways to determine commonly needed data about your bug.

Software Version: The version often be found within the Help menu in a graphical program. For a console utility, the program's man page should tell you what flag to use to print out the version (oftentimes, this involves typing --version after the command).
Operating System: There are many ways to determine the operating system you are running, but running uname -sr is one way of doing it.
Architecture: Two of many ways to determine the architecture of your processor are with uname -p and arch.

Reproducing Errors

Oftentimes, the information you send the developer just isn't enough. In order to understand what was going on "under the hood", so to speak, the developer will need to reproduce the error independently. Therefore, be ready to provide the developer with a step-by-step procedure with which he should be able to reproduce the error. If you feel that there the error is only related to the program, then a good place to start might be the initial execution of that program.

While a pixel-by pixel description of how you clicked on things is probably not necessary, it is important that you describe the method through which you did something. For example, a program may have several different methods of printing a document: a keyboard shortcut, a menu item, or a taskbar button, perhaps. You need to document which method produced the error.

Filling Out a Bug Report

The common actions pane at bugzilla.redhat.com. Click "Enter a new bug report" to begin.

Once you have successfully logged into the Bugzilla system and collected the necessary data, you can proceed with filing the report. Again, remember to make sure your bug hasn't already been filed by somebody else.

After logging in at https://bugzilla.redhat.com, you should see a side pane with common actions. Click on "Enter a new bug report".

After starting your bug report, you will be prompted to choose the project your bug is in. If you experience a bug using Fedora Linux, then you should probably click "Fedora" here. The next menu will present options for categories within the project you selected. If you found a bug in some software, you should probably just click "Fedora". Each category has a short caption to help you choose one. If you find an error in the documentation, for example, you may want to click "Fedora Documentation" instead.

If, for some reason, you really just can't decide where your bug belongs, don't give up. Just submit it somewhere, and the developers will reassign it to the appropriate project if necessary.

Once you have selected your bug's category, you will need to fill out the actual report. There are two methods for doing this; you can use the standard form or the guided form. The standard form is less verbose but easier to use if you know what you're doing. The guided form is recommended for new users.

Either way, make sure you have all the information you collected earlier, and start to fill in the fields.

Guided Form

The guided form provides an easy step-by-step method for filing bugs. By default, however, you will see the standard form. To switch to the guided form, click "Guided" in the second sentence on the page ("You may also use the Guided bug entry page for a easier step by step method. "). The guided form involves three steps.

First, determine if your bug has already been reported. The first step will allow you to search through bugs on record so you can ensure that your bugs is not already registered in Bugzilla.

Next, you need to give detailed information about your bug. Fill in each of the queries:

Component: Choose the name of the software that is giving you trouble. Depending on your bug, this might also be a documentation file or other component of Fedora.
Hardware Platform: This is your architecture that we determined earlier. If, for some reason, you are unsure of your platform, you can probably choose i386; however, make every effort to be sure of your architecture if you can.
URL: This is an optional field, and you can leave it out unless it applies to you.
Summary: Fill in a short, one sentence description of the problem. For example, "Saving file in .tiff format causes program to exit."
Details: This is your long version of the issue. Be as specific as possible. Make sure to give a rational, complete depiction of the problem; saying "The print button is broken" is not sufficient.
Reproducibility: This is a very important field. Does this happen every time you follow some procedure? Does it only happen on Tuesdays? Was it only once?
Steps to Reproduce: As discussed earlier, provide the steps you followed to reach the bug. If the problem cannot be reproduced, say so in "Reproducibility" and give the steps to the best of your memory.
Actual Results: What happened when you reached the bug?
Expected Results: What do you think should have happened?
Additional Information: If there's anything else you feel the developer need to know, you can put it here. This might be an error message from console output, or it might be the model of your camera that was connected when the bug occurred.
Severity: When reporting the severity of the issue, be reasonable. Try to be objective. Remember that, although the error may inconvenience you, it may not actually be a big deal. Each severity level has a caption that should help you decide.
Security: If you have identified a security-compromising problem, it needs to be noted here. These can often be serious issues.

In guided mode, there is no button for creating an attachment. If you have a screenshot, error log, stack trace, or any other important information you want to submit, you'll have to use the "Create a new Attachment" link on the bug after you submit it.

Finally, click submit, and check your email periodically for updates on the problem or clarification questions from developers.

Search

How to file a bug report

Contents