From Fedora Project Wiki
Line 53: Line 53:
=== 避免重复的bug报告===
=== 避免重复的bug报告===


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.
有时,您能找到的最重要的信息是您发现的bug是否已经被其他用户报告过。当同样地报告在bugzilla上报告过多次时,开发者的效率会降低,因为他们需要重复的阅读同样地bug报告。在Bugzilla系统中,请使用搜索功能来查找任何您要报告的bug的信息。
[[Image:BugSearch.png|frame|right|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.
[[Image:BugSearch.png|frame|right|当您单击“Search Existing Bugs”链接后,您应当能看到这个简单的搜索框]]


=== Finding Common Information ===
当您登录到Bugzilla后,查看您的'''常用活动(Most Common Actions)'''面板(界面左侧),并单击“查找已有Bug(Search Existing Bugs)”(请参见“提交Bug报告”项下的图)。当令找到搜索表单后,您能使用不同的选项和不同的关键字来搜索符合您问题的bug。高级搜索页提供了更多的灵活性,但它非常复杂。您看到的简单的表单应当能够胜任大多数的验证bug报告存在性的任务。在产品(product)中选择(Fedora)——除非您确信其他的选项更为合理。
 
确认一个bug是否已经被提交的步骤很容易被忽略。如果这使您产生困扰,提交一个bug报告永远比仅仅是忽略它要好。但是,开发者会被海量的重复bug报告淹没,所以在提交您的bug报告前,考虑搜索一下现有的bug库。
 
=== 寻找共有信息 ===


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''.   
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''.   

Revision as of 12:37, 25 October 2011

文档摘要:

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了。

收集您要提交的信息

在您提交一个bug之前,请您尽可能多的收集希望我们知道的信息。在您收集信息的时候,请确保至少让我们知道:

  • 这个bug已经被报告过了吗?
  • 您想抱怨的软件名称和版本
  • 当bug发生时您正在做什么?您准备去做什么?出现了什么问题?(如果有错误代码,请您一定告诉我们错误代码)
  • 您使用的操作系统(以及版本)以及
  • 您计算机的[指令集架构]。

另外,只有在极为少数的情况下,开发者只需要弄明白上面这些问题就可以解决您报告的问题。请您考虑报告bug时附上其他的信息,例如:问题产生时您正在运行的其他程序,任何可能与您运行的程序交互的外设(如打印机,扫描仪,相机等),与其他软件同时出现问题(其他程序在您运行的软件出现问题的同时也出现了问题),以及出现错误的日期与时间。开发者知道的越多,就有越多的帮助他们定位故障原因的线索。

避免重复的bug报告

有时,您能找到的最重要的信息是您发现的bug是否已经被其他用户报告过。当同样地报告在bugzilla上报告过多次时,开发者的效率会降低,因为他们需要重复的阅读同样地bug报告。在Bugzilla系统中,请使用搜索功能来查找任何您要报告的bug的信息。

当您单击“Search Existing Bugs”链接后,您应当能看到这个简单的搜索框

当您登录到Bugzilla后,查看您的常用活动(Most Common Actions)面板(界面左侧),并单击“查找已有Bug(Search Existing Bugs)”(请参见“提交Bug报告”项下的图)。当令找到搜索表单后,您能使用不同的选项和不同的关键字来搜索符合您问题的bug。高级搜索页提供了更多的灵活性,但它非常复杂。您看到的简单的表单应当能够胜任大多数的验证bug报告存在性的任务。在产品(product)中选择(Fedora)——除非您确信其他的选项更为合理。

确认一个bug是否已经被提交的步骤很容易被忽略。如果这使您产生困扰,提交一个bug报告永远比仅仅是忽略它要好。但是,开发者会被海量的重复bug报告淹没,所以在提交您的bug报告前,考虑搜索一下现有的bug库。

寻找共有信息

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.
Note.png
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