openSUSE:错误报告 FAQ

跳转到：导航，搜索
错误
提交错误报告 - Bug 报告常见问题 - Bug 定义 - 最令人恼火的 Bug - 测试 - 测试会议 - Bug Day - openQA
本文档描述了如何使用 bugzilla.opensuse.org 上的 Bugzilla，并列出了关于错误报告的常见问题及其解答。

您希望获得哪种反馈？

我们喜欢获得积极和消极的反馈 - 以及改进建议。

  • 积极的反馈意味着我们希望听到系统已成功安装并正常工作，某些区域已测试并且这些区域正常工作。请在 opensuse@opensuse.org 邮件列表上报告此信息。积极的反馈记录在我们的 testdb 中。
  • 对于负面反馈，这意味着遇到的任何问题，我们使用 Bugzilla。请为遇到的每个问题提交单独的 Bug 报告。本常见问题解答的其他部分详细解释了如何提交 Bug 报告。

进一步阅读

常规 Bug 处理

最初应填写哪些字段？哪些字段应该更改，哪些字段不应该更改？

  • 组件
    注意：并非所有安装过程中的 Bug 都是 YaST 的错，例如，它们可能是内核问题。
  • 平台
    如果您认为它是平台无关的，请使用“all”，否则请说明您的平台。
  • 摘要
    查看摘要的人应该了解正在发生什么。
  • Bug 描述
    添加有关 Bug 的所有详细信息。请注意，您不应该说“参见摘要”，因为摘要可能会被更改。
  • 重现方法？
    这非常重要，值得在 Q 中进行额外说明：1.1.5
  • 严重程度
    选择正确的严重程度。仅当它阻止您使用该产品时，才将其标记为“阻碍程序”。如果认为我们不应该在产品中修复此 Bug 的情况下发布，则可以使用 SHIP_STOPPER 标记。
  • 其余
    您不需要填写任何其他字段，默认值即可。

报告 Bug 后会收到任何反馈吗？

是的，如果您不更改您的 Bugzilla电子邮件首选项以排除接收 Bug 邮件，您将通过电子邮件收到有关任何更改的通知。

如果您有疑问或只是想发表评论，请不要将电子邮件发送到 Bugzilla 自动生成的评论者地址。您应该使用 Bugzilla 网页界面进行通信，因为这是相关信息对所有相关人员可用的唯一方法。

哪些字段应该更改，哪些字段不应该更改？

作为非开发人员，您通常只需添加其他评论或将自己添加到抄送列表中。如果 Bug 具有NEEDINFO标记，请记住在提供所有信息后勾选“清除 needinfo 请求”复选框。

如果当前 openSUSE 版本包含与旧版本中已存在的相同（或类似）Bug，我应该怎么办？

您可以选择更改软件包版本并在评论中写一些类似“此 Bug 是为 openSUSE x.y 报告的，仍然存在于 openSUSE u.v。我正在调整版本”。如果 Bug 已设置为RESOLVED，您应该重新打开它。

人们因为我在 Bugzilla 的“重现方法”字段中输入“安装 openSUSE x.y-Beta-z”而生气了。为什么？

因为这完全是无用的信息 - 冗余且没有任何帮助来重现 Bug。我们可以从 Bugzilla 组件列表中选择“安装”来判断 Bug 是关于安装的，并且我们可以从紧挨着该列表的版本列表中判断您安装了哪个版本。

我们真正需要知道的是您做了什么以及如何做的 - 例如“从 CD1 启动，选择“安装”，选择语言“克林贡语”，保持安装设置不变，确认安装，看着您的硬盘着火”。

不，这真的，真的不是吹毛求疵 - 我们有如此多的安装模式和如此多的安装路径，从日志文件中弄清楚所有这些信息需要花费大量时间。您已经掌握了这些信息，请在字段中输入这些信息。

当然，当您报告其中一个最终硬件配置对话框（如打印机、电视卡等）中的帮助文本 Bug 时，我们不需要如此详细的描述 - 但我们确实需要到达出现问题的地点的步骤。我们有如此多的对话框，很难弄清楚您指的是哪个对话框以及您遵循了哪条路径。

人们对我只在 Bugzilla Bug 描述中写“参见主题”感到非常不高兴 - 但我的主题确实解释了一切！坚持让 Bug 报告者在描述字段中重复这些内容不是吹毛求疵吗？

不，完全不是。

主题会不断更改。您报告的问题可能只是冰山一角 - 实际问题可能出现在完全不同的地方，然后那些了解该地方的人当然会相应地更改主题。这反过来意味着您原来的主题将会丢失。

因此，很明显，主题不是存储相关信息的场所，而报告的问题绝对是 Bug 报告中最重要信息。

这也很懒。花时间正确地做一次，但与该 Bug 合作的每个人都必须一遍又一遍地在各处搜索相关信息。

此外，主题应该是简洁的 - 但 Bug 描述应该是解释性的。这两个要求是矛盾的。

为什么我的报告“XYZ 不工作”没有被认真对待？

我们需要更多信息才能采取行动。XYZ 的哪个版本不起作用？在什么情况下？

Bug 标记 NEEDINFO

该 NEEDINFO Bug 标记是什么意思，应该如何处理？

NEEDINFO表示 Bug 所有者（当前正在处理该 Bug 的人）需要有关该 Bug 的更多信息 - 通常来自 Bug 报告者。

如果您发现您报告的 Bug 具有NEEDINFO标记，请查找评论中的问题或请求提供更多信息（例如日志等）。

如果是这样，请回答该问题或提供相应的信息，并勾选复选框“清除 needinfo 请求”以从 Bugzilla Bug 详细信息页面中删除NEEDINFO标记。

请优先使用 Bugzilla 网页界面来回答问题和附加日志。除非有充分的理由，否则请勿通过电子邮件发送这些信息。通常会有不止一个人处理同一个错误，为了确保适当的修复，这些信息应该对他们所有人开放。

为什么我需要勾选复选框来移除 NEEDINFO 标记很重要？这不应该是错误负责人（bug owner）的责任吗？

不，这是回答所提问题或提供所请求信息的人的责任。

错误负责人使用NEEDINFO以便他们可以更轻松地查看他们实际可以处理的错误（设置为CONFIRMED或IN_PROGRESS）以及哪些错误因为缺少重要信息而停滞不前。

我们的维护者收到如此多的自动邮件，以至于在高峰期（例如 Beta 阶段）他们无法合理地对每一封邮件都做出单独回复，因此在某个时候他们不得不依赖错误列表——然后就有可能被忽略一些请求的信息现在已经可用，并且可以恢复错误处理。

因此，每个错误报告者都有兴趣在问题得到解答后移除NEEDINFO标记。

当然，有时你可能会很幸运，错误负责人意识到请求的信息现在已经可用并移除NEEDINFO标记，但依赖运气通常不是一个好的策略。

如果我没有回答带有 NEEDINFO 标记的错误会发生什么？

一个带有NEEDINFO标记超过一个月的错误可能会被解决为NORESPONSE并附上一条友好的消息，例如“请求的信息未提供超过 4 周，解决为 NORESPONSE。一旦提供信息，请重新打开错误。”

作为错误筛选的一部分，其他开发人员也可能会对错误执行此操作。

错误状态 RESOLVED

如果我在新版本或更新中看到问题已解决，我应该将错误标记为 RESOLVED 吗？

如果更改日志中注明该错误已修复并且更新已发布到 openSUSE，您可以将错误标记为 RESOLVED。

如果上游已经修复了此问题，但更新尚未在 openSUSE 中，您可以评论该错误（如果开发人员尚未意识到这一点）。

SUSE 安全漏洞的特别说明

如果错误归属于“Security”组件，或者标题类似于以下内容

(CVE-2017-9872) VUL-0: CVE-2017-9872: lame: The III_dequantize_sample function in layer3.c in mpglib...

请勿手动关闭这些错误，因为这些错误由 SUSE 员工使用内部软件处理。

根据一位 SUSE 员工的说法

一旦维护者完成对特定错误的处理，他们应该将其重新分配给 security-team@suse.de 错误负责人，然后我们将从那里进行处理。我们为此附带了一些跟踪和工具，并且在确保我们这边一切正常之前关闭错误可能会混淆机制；-)。

错误状态 VERIFIED

如果我在新版本或更新中看到问题已解决，并且有人将状态更改为 RESOLVED，我应该将错误标记为 VERIFIED 吗？

[待定]

Bug Status WONTFIX

此部分已移动到 Bug Status WONTFIX

如何报告针对...的错误

有关如何报告不同组件（例如 Kernel、KDE 或 Yast）的错误的更多信息，请参阅 openSUSE:Submitting bug reports

openSUSE 文档

在 Bugzilla 中报告 openSUSE 文档缺陷（组件：“Documentation”）。

Beta 测试

我想参与 openSUSE 的 Beta 测试。我应该联系谁？

openSUSE 是开放的。只需订阅 openSUSE 项目邮件列表，并像在 openSUSE:Submitting bug reports 中描述的那样报告您的错误。

我想参与 SLES 或 SLED 等其他产品的 Beta 测试。我应该联系谁？

并非所有这些产品都有 Beta 程序，但如果有，它们可能可以通过 Novell Beta Program 访问。

从 "https://en.opensuse.net.cn/index.php?title=openSUSE:Bug_reporting_FAQ&oldid=176120" 检索