如何对 Bug 进行分类以及 Bug 的生命周期是怎样的？

Question

Ubuntu 中的所有错误都有生命周期。此外，每个错误都有一个“状态”，有助于解释其生命周期。在 Ubuntu 中，每个错误在其生命周期继续时都会设置各种状态。

虽然这一切都在分诊指南，我将（暂时，因为我没有大量的时间以文字形式描述这个过程，但稍后我会）发布 Bug Squad 为此提供的“流程图”（点击此处查看流程图来源）。每个状态（同时）可以在错误/状态 BugSquad 文档，但我也在这里记录了它们。

（请注意，以下信息可能与 wiki 上的文档不符，您应该参考 wiki 来获取最新的信息。）

以下是错误的每个状态指示器的描述：

新的：
- 错误已以此状态提交
- 他们有时缺乏信息和
- 所有这些都不应该被分类
不完整：
- 如果您必须向记者提问，请将错误设置为“未完成”
- 要求提交者在评论中提供任何必要的信息，并确保您订阅了错误报告，这样您就可以通过电子邮件收到有关该错误的任何更新。
- 有些错误从未得到提交者（也称为“原始发布者”或“OP”）的回应。这些错误将在 60 天内由 Launchpad 自动过期，从设置为未完成之日起计算。无需对它们采取行动（实际上，更改错误将重新开始过期期限）。请注意，这适用于 Ubuntu 项目（即名称中带有“(Ubuntu)”的错误任务）。其他项目可能会或可能不会设置自动未完成错误过期。
- 如果任何人（包括您）对该错误提出评论，则 60 天的到期时钟将被重置。
观点：
- 状态“意见”表示对某个错误存在不同意见，人们可以继续讨论，但项目或软件包维护者需要转而从事其他工作，并认为问题已解决。这个想法是可以将错误标记为已解决，这样开发人员就不会浪费时间，但讨论仍可继续进行。
- 此状态“意见”被视为一次实验，将受到密切监控。
无效的：
- 当错误报告不包含足够的信息来确定它是否是一个错误时，应该使用此状态，即使它已为报告者解决
- 如果报告的问题根本不是错误，也应该使用这种方法，例如用户错误
- 应谨慎使用，因为标记为无效的错误不再显示在默认搜索中
- 在使错误无效之前，请务必三重检查
已到期：
- 此状态与无效状态类似，但专门用于未完成时间过长的错误。（见上文。）
- 此状态只能通过使用 launchpadlib 或电子邮件界面来设置。
- 与无效错误一样，过期错误不会出现在默认搜索中。
确认的：
- 另一位报告者遇到了同样的错误，这可能以重复的错误或错误评论的形式出现
- 已确认的错误需要原始报告者以外的其他人的确认
- 这有助于确保该错误适用于整个 Ubuntu，而不是报告者系统的问题，因此......
- 请不要确认您自己的错误！
分类：
- UbuntuBugControl 的一名成员认为该报告对真正的错误进行了足够详细的描述，开发人员可以开始修复它。（另请参阅下面的提示）
- 当您确信它应该由开发人员查看并且具有足够的信息时，请使用此方法
- 虽然不要求在发生任何上游转发之前对错误的 Ubuntu 任务状态进行分类
- 对于 Linux 上的 bug，Triaged 表示该 bug 已经通过上游主线内核测试
进行中：
- 如果你正在修复错误，将其设置为“进行中”，以便人们知道发生了什么
- 正在处理的错误应该分配给正在处理它们的人员
已提交修复：
- Ubuntu 错误任务：更改正在等待处理并将很快上传（这就是 Bugzilla 中的 PENDINGUPLOAD）
- 当更新的软件包存在于建议的存储库（即 hardy-proposed）中时，也会使用 Fix Committed
- 已提交的修复是不是当补丁附加到错误时使用
- 上游错误任务：修复已在 CVS/SVN/bzr 中或已提交到某个地方
修复已发布：
- Ubuntu 错误任务：修复已上传至官方 Ubuntu 存储库
- 注意：这不包括 -proposed 即 hardy-proposed
- 请随时添加更新日志作为评论，以便人们知道在哪个软件包版本中修复了错误
- 如果在当前开发版本中修复了错误，则该错误已修复。如果该错误还需要在稳定版本中修复，请使用“目标发布”链接将其提名为该版本。
- 上游错误任务：发布 tarball 已公布并可供公众使用
无法修复：
- 当错误修复存在太大争议时，有时会使用此状态
- 它最常用于发布目标中的错误，这些错误不会在特定版本中修复，但可能会在以后修复
- 它也可能用于开发人员不想实现的功能请求

（这里的格式与 wiki 略有不同，因为这里的格式比较有限）

相关问题与答案：
重要性值：Ubuntu Bug 的重要性值是如何确定的

Answer 1