How to file a bug report/zh-cn

In other languages: English (en) 中文（中国大陆） (zh-cn) [edit]

文档摘要:

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: Bugs and feature requests

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

Lead Writer: danielsmw

---

如何提交一个bug

这个页面描述了向Fedora开发者们提交软件Bug的流程。bug的定义是："在程序设计中的术语，是指在软件运行中因为程序本身有错误而造成的功能不正常、死机、数据丢失、非正常中断等现象。" (维基百科)。 当前文档针对Fedora使用的Red Hat's Bugzilla system。 但用户也很可能可以找到对其他Bug反馈系统（Bugzilla implementations）上Bug的提交有帮助的信息。

Bug报告是Fedora改进软件质量的重要组成部分。没有用户反馈，许多问题将无法解决，因此学习使用Bugzilla反馈工具是一个重要的用户技能。 注意：不是所有你在Fedora中使用的东西都是Fedora项目和包维护者的责任范围。 例如，如果你正在使用ForbiddenItems，那么您不应该就这个问题向Fedora开发者提交Bug. 如果你安装了非Fedora包管理器中的源，你同样也不应该向Fedora提交相关的bug报告。

Fedora是一个操作系统，而且并不是您计算机上的每一个程序都由Fedora项目拥有且负有责任。请在填写bug报告前检查ForbiddenItems清单。任何在该清单上的程序或工具的问题都无法由Fedora项目组解决。

为什么我们提交Bug

作为最终用户，遇到妨碍您工作/娱乐的bug往往是令人沮丧的经历。大部分时候，忽略bug并仅仅找一条能完成工作的不同的方法是一条有效的用户经验。但从长远眼光看，不去报告bug意味着您遇到的问题将永远得不到解决。不同于许多人在大的软件公司报告bug的经验，开源软件用户会发现软件开发者会对bug报告进行回复并通过电子手段与您联系。

这对您意味着什么呢？这意味着通过报告bug，您可以确切的知道，您的体验被开发者关注。您提交的bug可能不会被立即修复，但维护您使用的软件的程序员将会了解您报告中提到的问题，并在未来修复您提交的问题。

创建Bugzilla账户

Bugzilla是一个开源的bug跟踪工具，它用于管理用户提交的问题、缺陷和功能障碍。Bugzilla一般可以用web界面访问-也就是说，您通过您的WEB浏览器访问，因而您不需要下载任何新的软件。要在Bugzilla上提交一个Bug，您需要首先创建一个用户账户。

1. 打开您的浏览器，并访问 bugzilla账户创建页面.
2. 用您经常使用的Email地址请求一个账户
3. 检查您的电子邮箱，知道您收到一封账户创建确认邮件
4. 单击该邮件中的地址，填写并提交浏览器导航到的表单。

注意：如果您没有在三天内单击Email中的确认链接，您将需要从头开始您的申请。

当您创建了一个账户后，您就可以用您的email地址和密码登录到Bugzilla了。

Gathering Information

Before reporting a bug, collect as much relevant information as possible. As you collect this information, make sure you at least know the following:

• Whether or not the bug has already been reported
• The name and version of the buggy software,
• A 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 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.

Avoiding Duplicate Bug Reports

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 in Bugzilla, developers are slowed down by having to read all of them redundantly. In the Bugzilla system, use the search feature to see if you can find an already-reported version of your bug.

After clicking on the "Search Existing Bugs" link, you should see this simple bug-searching form.

After you have logged into Bugzilla, look for your Most Common Actions pane on the left and click the "Search Existing Bugs" link (see figure under Filing a Bug Report). Once you have arrived at the search form, you can play with the different options and use various keywords to search for a bug that matches your issue. The Advanced Search tab offers more flexibility, but is also very complex. The simple form should be enough to verify the existence of a bug report. Choose Fedora as the product unless you are confident that another choice is better here.

The importance of determining whether or not a bug has already been filed cannot be stressed enough. If in doubt, it is always better to file a bug than to ignore it; however, developers can be slowed down by the weight of duplicate bug reports, so ensure that you conduct a thorough search before filing yours.

Finding Common Information

Your bug report will almost always contain the information listed above. More often than not, though, additional information will be needed. It is important to know ways to determine frequently needed data about your bug. This might involve using a terminal. To open a terminal in Gnome, click Applications->System Tools->Terminal.

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). To view the man page, type man program, where program is the software you are trying to check.

Operating System

There are many ways to determine the operating system you are running, but running uname -sr in a terminal is one way to do it.

Architecture

Two of many ways to determine the architecture of your processor are with uname -p and arch.

To run any of the commands above, such as uname, just type your full command in the terminal window and press [ Enter ].

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 on his own. Therefore, be ready to provide the developer with step-by-step instructions on how 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 tell him to start might simply be running 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 basic outline of how you made the bug appear. 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 tell the developer 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 start to file 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 are experiencing 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 software application, a documentation file, or another 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 an 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" does not describe the problem enough.

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 was supposed to happen?

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.

Further Reading

• Bugs and feature requests - A more advanced guide to filing bugs
• Bugzilla Etiquette - A guide to being polite using Bugzilla.
• Filing Bugs Effectively - A commentary on writing effective bug descriptions.