Bug 报告 常见问题解答

Jump to: navigation, search

Susemini.png 本文处于需要翻译的文章的状态,欢迎您积极参与翻译与修订。 翻译人员:无,修订人员:无。

Contents

常规bug处理



本文档描述了如何使用 bugzilla 在 bugzilla.novell.com.


哪些域应该初始时被填充? 我应该改哪些域而不能改哪些域?

  • 组件 (Component)
    注: 不是所有安装时出现的问题都是YaST的错误,例如它们可能是内核的错误。
  • 平台 (Platform)
    如果您认为这个bug是与平台无关的请使用 “all”,否这请指明您的平台。
  • 概要 (Summary)
    当人们看到了概要就应该知道发生了什么。
  • Bug描述 (Bug discription)
    给出这个bug的细节。请注意您不应该说“见概要”,因为概要可能被改变。
  • 如何重现? (How to Reproduce?)
    这非常重要,因此值得附加的解释 在 1.1.5
  • 严重程度 (severity)
    请选择正确的严重程度. 如果它阻止了您使用该产品,把它标记为 “blocker" 。 如果您认为我们在修正这个bug之前不应该发布该产品,可以使用SHIP_STOPPER 标志。
  • 其他 (The rest)
    您不需要填其它域了, 默认的就可以了。


报告bug之后我会得到反馈么?

是的, 如果您的信息没有变化,我们会通过邮件通知您任何改变.

如果您被问到一些问题并且需要回答, 请不要给commenter地址发送邮件,因为那是bugzilla自动生成的。 您应该通过 bugzilla 的web界面来交流,因为那是让所有相关人员得到相关信息的唯一方法。


哪些域我应该改变而哪些域不应该?

作为非开发者,您一般情况下只应该增加一些附加的评论,或者把您自己加到抄送列表.。如果bug处在 “NEEDINFO" 状态,记得给出了所有的信息后把它设为 “ASSIGNED"。


如果当前版本的openSUSE出现了和以前版本相同或相似的bug,我该怎么做?

我建议改变该bug的版本并且在评论中写上类似“这个bug在openSUSE x.y被报告过,但是在openSUSE u.v版本中仍然存在,我调整了它的版本”的内容。如果这个bug之前被close了,您应该reopen它。


我在“如何复现”域写道“安装openSUSE x.y-Beta-z”,这使人们疯狂,为什么?

因为这是完全没用的信息 - 多余而且对重现这个bug没有任何帮助。我们可以知道这是关于安装的bug,因为您在Bugzilla组件域的列表中选中了“Installation”,而且我们通过它右边的发行版域能知道您安装的版本。

我们真正需要的是您做了什么和您怎么做的 - 例如“从CD1启动,选择“安装”,选择语言“Klingon”,保留安装默认设置,确认安装,看到您的硬盘开始闪烁。”

真的,这并不是吹毛求疵 - 我们有太多的安装模式和安装路径了,如果从记录文件中获取这些信息需要太长时间了。而您恰好能提供这些信息,因此请您把它填到“如何复现”那个域。

当然,我们不需要这么细节的信息 - 如果您正在报告一个关于帮助文字的bug,它出现在最终的硬件配置对话框(例如打印机、电视卡等)- 但是出现这个bug之前的操作步骤我们还是非常需要的。我们有非常多的对话框,因此得到您是指的哪一个和相应的步骤并不容易。


人们仅仅因为我在Bugzilla的bug描述域中写道“请见标题”而变得很不高兴 - 但是我的标题确实解释得非常清楚了!这难道不是纯粹在挑毛病么,非坚持在描述域中再重复一遍?

不,完全不是这样的。

标题会随时改变。您报告的问题可能只是冰山的一角 - 真正的问题可能与此完全不同,因此知道真正原因的人当然会修改标题使其反映真正的问题。这也就意味着您原始的标题丢失了。

所以这已经非常清楚了:标题不是存放相关信息的地方,一个bug报告最重要的信息是问题的描述。

同样的,把所有的信息都堆在标题而描述仅参考标题也是一种非常不好的风格。这是纯粹的偷懒行为。这样做是仅花了您一次时间,但所有和这个bug有关的人员都要一次次的搜索所有的地方来得到相关的信息

除此之外,标题应当简明 - 而bug描述应该是详细的解释。这两个要求是矛盾的。


Bug的状态 NEEDINFO



What does that NEEDINFO bug status mean, and how should this be handled?

NEEDINFO means that the bug owner (the person who is currently working on that bug) needs more information about that bug - usually from the bug reporter.

If you find a bug you reported is set to NEEDINFO, look for a question or a request to supply more information (such as logs etc.) in one of the last comments.

If this is the case, please answer that question or provide that information, respectively, and set the bug status to ASSIGNED - click on Accept bug (change status to ASSIGNED) in the Bugzilla bug details page.

Please prefer bugzilla web interface for answering questions and attaching logs. Do not send this information by email unless you have serious reasons to do so. There are usually more people working on one bug and this information should be accessible for all of them to ensure quick fix.


Don't I become the bug owner when I change a bug's status away from NEEDINFO to ASSIGNED (with Accept bug (change status to ASSIGNED) in the Bugzilla bug details page)?

No, the bug owner remains the same, only the status changes. You can safely do that without fear that this bug will become your responsibility because of this.


Why is it important that I set a bug status away from NEEDINFO to ASSIGNED? Isn't that the bug owner's responsibility?

No, this is the responsibility of whoever answers the question that was asked or supplies the information that was requested.

Bug owners use NEEDINFO so they can more easily see what bugs they can actually work on (those set to ASSIGNED, NEW, or REOPENED) and which ones are stuck because important information is missing - NEEDINFO bugs no longer appear in their to-do list of open bugs.

This is why it is important that the bug status is set away from NEEDINFO to some other status - the bug owner might overlook the mail Bugzilla sends automatically for comment added to a bug, and then this bug might remain in status NEEDINFO for an indefinite period of time.

Our maintainers receive so many generated mails that at peak times (like during a Beta phase) they cannot reasonably react to each one individually, so at a certain point they have to resort to bug status lists - and then chances are that it is overlooked that some requested information is now available and work on a bug can resume.

So it is in the own interest of each bug reporter to change the bug status away from NEEDINFO after the questions are answered.

Of course, sometimes you can be lucky and the bug owner realizes that the requested information is now available and sets the bug status to ASSIGNED himself, but relying on luck is usually not a good tactic.

Please note that bugs which are assigned to the BNC-Screening-Team (mainly YaST- and X11-related problems) initially or during the process should not be set from NEEDINFO to ASSIGNED by the reporter or the person the information was requested from. This is because a change of this status almost always involves a reassignment which is done by this team. Changing this status might cause the specific bug to appear on the wrong listing and might therefore be not handled (reassigned) efficiently. Thank you for taking this into account.

Bug Status VERIFIED / CLOSED


Should I mark a bug as VERIFIED or CLOSE it when I see that the problem is solved in a new version or with the updates?

[TBD]


Bug Status WONTFIX


This section has been moved to Bug Status WONTFIX


How to report a bug against ...


For more information about how to report bugs for different components, as e.g. the Kernel, KDE or Yast, please follow Submitting Bug Reports


openSUSE Documentation


Report openSUSE documentation defects in Bugzilla (component: "Documentation") and for release products also add entries to Errata in the openSUSE 11.0 Documentation or Errata in the openSUSE 10.3 Documentation.


Beta Testing


I'd like to participate in testing betas for SUSE Linux. Whom shall I contact?

openSUSE is open. Just subscribe to the openSUSE Project Mailing Lists and report your Bugs like described in Submitting Bug Reports.


I'd like to participate in testing betas for other products like SLES or SLED. Whom shall I contact?

Not all these products have beta programs, but if they do have, they might be accessible via The Novell Beta Program.


你需要哪些反馈?

无论正面或者负面的反馈我们都欢迎 - 同时也欢迎提出改进意见。

正面的反馈意味着我们听到一个系统已经成功安装和运作,一些地区已经经过测试,可以正常工作。 请报告至我们的邮箱[1]。积极的反馈将会记录在我们的测试数据库里面。

对于负面的反馈,这意味着遇到的任何问题,我们使用Bugzilla来记录。请为您遇到的每个问题提交单独的错误报告。这个FAQ中有其他地方会详细解释如何提交错误报告。

此外,改善的想法,或称要求增加的功能,也是不可或缺的。有Package WishlistFeature Wishlist来添加这些想法特别的网页。

What is betatestdb.suse.de?

Note: betatestdb.suse.de was last updated for SUSE Linux 10.0 and access to it is password-protected. (The login you use for this wiki and bugzilla won't work.)

Betatestdb is a tool to see which packages have been tested by beta testers and if the tests have been successfull or not. This allows us to receive not only negative feedback (something is broken) via Bugzilla but also positive feedback that the packages are working and the product is stable.

For a large number of packages there are detailed testcases which contain a description what to do - either a special feature or the whole software package. Please follow these instructions and enter the results in betatestdb.

Note: To have a better view onto the packages, we separated the packages into different areas.