openSUSE:错误报告 FAQ
您想要哪种反馈？
我们希望收到正面和负面反馈——以及改进意见。
- 正面反馈意味着我们希望听到系统成功安装并正常工作，某些区域已测试且正常工作。请在 opensuse@opensuse.org 邮件列表上报告此信息。正面反馈记录在我们的 testdb 中。
- 对于负面反馈，即遇到的任何问题，我们使用 Bugzilla。请为遇到的每个问题提交一个单独的 Bug 报告。本常见问题解答中还有其他部分详细解释了如何提交 Bug 报告。
延伸阅读
- Simon Tatham (1999)。如何有效地报告 Bug。https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
通用 Bug 处理
最初应该填写哪些字段？我应该更改哪些，不应更改哪些？
- 组件
注意：并非所有安装过程中的 Bug 都是 YaST 的错，它们也可能是内核 Bug。 - 平台
如果您认为它与平台无关，则使用“all”，否则说明您的平台。 - 摘要
查看摘要的人应该理解发生了什么。 - Bug 描述
添加有关 Bug 的所有详细信息。请注意，您不应说“参见摘要”，因为摘要可能会被更改。 - 如何重现？
这很重要，值得在问题 1.1.5 中单独解释。 - 严重程度
选择正确的严重性。仅当它阻止您在该产品上工作时，才将其标记为“blocker”。如果您认为我们不应该在产品中发布此未修复的 Bug，则可以使用 SHIP_STOPPER 标记。 - 其余
您不需要填写其他任何字段，默认值即可。
报告 Bug 后会收到反馈吗？
是的，如果您不更改您的 Bugzilla电子邮件偏好设置以排除接收 Bug 邮件，您将通过电子邮件收到任何更改的通知。
如果您被提问或只是想评论，请不要将电子邮件发送到 Bugzilla 自动生成邮件中的评论者地址。您应该使用 Bugzilla Web 界面进行沟通，因为这是所有相关人员都可以访问相关信息的唯一方式。
我应该更改哪些字段，不应更改哪些？
作为非开发人员，您通常只需添加额外评论，或将自己添加到抄送。如果 Bug 设置了NEEDINFO标记，请记住在提供所有信息后勾选“清除 needinfo 请求”框。
如果当前 openSUSE 版本包含与已存在但针对旧版本提交的 Bug 相同（或类似）的 Bug，我该怎么办？
您可以更改包的版本并在评论中写上类似“此 Bug 是针对 openSUSE x.y 报告的，但 openSUSE u.v 仍然失败。我正在调整版本。”如果 Bug 已设置为RESOLVED，您应该重新打开它。
人们对我将“安装 openSUSE x.y-Beta-z”输入到 Bugzilla 的“如何重现”字段感到恼火。为什么？
因为这是完全无用的信息——多余且对重现 Bug 没有任何帮助。我们可以判断 Bug 是关于安装的，因为您从 Bugzilla 组件列表中选择了“Installation”，并且我们可以从旁边的发布列表中判断您安装了哪个版本。
我们真正需要知道的是您做了什么以及如何做的——例如“从 CD1 启动，选择“Installation”，选择语言“Klingon”，保留安装设置不变，确认安装，然后看着您的硬盘起火。”
不，这真的不是吹毛求疵——我们有如此多的安装模式和如此多的安装路径，从日志文件中找出所有这些信息需要很长时间。您已经有这些信息，请将其输入到该字段中。
当然，当您报告关于最终硬件配置对话框（例如打印机、电视卡等）中的帮助文本的 Bug 时，我们不需要如此详细的信息——但到达问题发生地的步骤我们确实需要。我们有如此多的对话框，不容易弄清楚您指的是哪一个以及您遵循了哪个路径。
人们非常不高兴，因为我只在 Bugzilla Bug 描述中写了“参见主题”——但我的主题确实解释了一切！坚持 Bug 报告者在描述字段中重复这些内容不是吹毛求疵吗？
不，完全不是。
主题总是在变。您报告的问题可能只是冰山一角——真正的问题可能在完全不同的地方，然后那些知道该地方的人自然会相应地更改主题。这反过来意味着您原来的主题将丢失。
因此，主题不是存储相关信息的地方应该很明显，而正在报告的问题无疑是 Bug 报告中最重要的信息。
将各种信息倾倒在主题中，然后只引用主题，这简直是糟糕的风格。这纯粹是懒惰。您一次性正确地完成它会花费一些时间，但每个处理该 Bug 的人都必须一遍又一遍地在所有地方搜索相关信息。
此外，主题应该简洁——但 Bug 描述应该具有解释性。这两个要求是矛盾的。
为什么我的报告“XYZ 不工作”没有被认真对待？
我们需要更多信息才能采取行动。哪个版本的 XYZ 不工作？在什么情况下？
Bug 标记 NEEDINFO
NEEDINFO Bug 标记是什么意思，应该如何处理？
NEEDINFO表示 Bug 所有者（当前正在处理该 Bug 的人）需要更多关于该 Bug 的信息——通常来自 Bug 报告者。
如果您发现您报告的 Bug 设置了NEEDINFO标记，请在最新评论中查找问题或请求提供更多信息（例如日志等）。
如果出现这种情况，请回答问题或提供信息，并勾选复选框"清除 needinfo 请求"以从 Bugzilla Bug 详细信息页面中移除该 Bug 的NEEDINFO标记。
请优先使用 Bugzilla Web 界面来回答问题和附加日志。除非您有充分理由，否则不要通过电子邮件发送此信息。通常有不止一个人在处理一个 Bug，所有这些人都可以访问此信息以确保适当的修复。
为什么勾选该框以移除 NEEDINFO 标记很重要？这不是 Bug 所有者的责任吗？
不，这是回答问题或提供所请求信息的人的责任。
Bug 所有者使用NEEDINFO以便他们更容易地查看他们实际可以处理的 Bug（那些设置为CONFIRMED或IN_PROGRESS）以及哪些 Bug 因缺少重要信息而停滞不前。
我们的维护者收到如此多的自动邮件，以至于在高峰期（例如在 Beta 阶段），他们无法合理地单独回复每一封邮件，因此在某个时候他们不得不求助于 Bug 列表——然后就有可能忽略某些请求的信息现在可用并且可以恢复对 Bug 的工作。
因此，每个 Bug 报告者在问题得到回答后删除NEEDINFO标记符合其自身利益。
当然，有时您可能会很幸运，Bug 所有者会意识到请求的信息现在可用并自行删除NEEDINFO标记，但依靠运气通常不是一个好策略。
如果我不回复带有 NEEDINFO 标记的 Bug，会发生什么？
一个带有NEEDINFO标记超过一个月的 Bug 可能会被解决为NORESPONSE并附带友好消息，如“请求信息超过 4 周未提供，解决为 NORESPONSE。提供信息后请重新打开 Bug。”
作为 Bug 筛选的一部分，其他开发人员也可能对 Bug 执行此操作。
Bug 状态 RESOLVED
当我在新版本或更新中看到问题已解决时，我应该将 Bug 标记为 RESOLVED 吗？
如果在更新日志中注明 Bug 已修复且更新已发布到 openSUSE，您可以将 Bug 标记为 RESOLVED。
如果上游已修复此问题但更新尚未在 openSUSE 中，如果开发人员尚未意识到此问题，您可以对 Bug 进行评论。
如果 Bug 归档在“Security”组件下或标题类似于以下内容
- (CVE-2017-9872) VUL-0: CVE-2017-9872: lame: mpglib 中 layer3.c 的 III_dequantize_sample 函数...
请不要手动关闭这些 Bug，因为它们由 SUSE 员工使用内部软件处理。
根据 SUSE 员工的说法
- 一旦维护者完成对特定 Bug 的工作，他们应该将其重新分配给 security-team@suse.de 的 Bug 所有者，我们将从那里开始处理。我们有一些跟踪和工具附加到它，并且在没有确保我们这边一切正常的情况下关闭 Bug 可能会混淆机制 ;-)。
Bug 状态 VERIFIED
当我在新版本或更新中看到问题已解决后，有人将状态更改为 RESOLVED 时，我应该将 Bug 标记为 VERIFIED 吗？
[待定]
Bug Status WONTFIX
此部分已移至 Bug Status WONTFIX
如何报告针对...的 Bug
有关如何报告不同组件（例如内核、KDE 或 YaST）的 Bug 的更多信息，请参阅 openSUSE:提交 Bug 报告
openSUSE 文档
在 Bugzilla 中报告 openSUSE 文档缺陷（组件：“Documentation”）。
Beta 测试
我希望参与 openSUSE Beta 测试。我应该联系谁？
openSUSE 是开放的。只需订阅 openSUSE 项目邮件列表，并按照 openSUSE:提交 Bug 报告 中的描述报告您的 Bug。
我希望参与 SLES 或 SLED 等其他产品的 Beta 测试。我应该联系谁？
并非所有这些产品都有 Beta 项目，但如果它们有，它们可能可以通过 Novell Beta 项目访问。