如何对Bugs进行分类以及bug的生命周期是什么？
如何对ubuntu中的错误进行分类以及bug的生命周期是什么？
此外，“每个bug的’状态’是什么意思，它是如何确定的”
Ubuntu中的所有错误都有生命周期。 同样，它们每个都有一个“状态”，有助于解释它的生命周期。 在Ubuntu中，每个bug的生命周期都会继续，并在其上设置各种状态。
虽然在分类指南中非常详细地记录了这一点，但我会（因为我没有足够的时间在文本中写下这个过程，但我稍后会发布）提供的“流程图” Bug Squad为此（ 点击此处查看流程图的来源 ）。 每个状态（平均时间）可以在Bugs / Status BugSquad文档中解释，但我也在这里记录了它们。
（请注意，以下信息可能与Wiki上的文档已过期，您应该参考Wiki获取最新信息。）
以下是对错误的每个状态指示器的描述：
- 新：
- 以此状态提交错误
- 他们有时缺乏信息和
- 所有这些都应该是无关紧要的
- 未完成：
- 如果您必须询问记者问题，请将错误设置为“未完成”
- 要求提交者在评论中提供任何必要的信息，并确保您自己订阅错误报告，以便通过电子邮件获得有关错误的任何更新。
- 提交者永远不会回复一些错误（也称为“原始海报”或“OP”）。 这些错误将由Launchpad在60天内自动过期，从设置不完整的那天算起。 没有必要对它们采取行动（实际上，更改错误将重新启动到期时间）。 请注意，这适用于Ubuntu项目（即那些名称中包含“（Ubuntu）”的bug任务）。 其他项目可能会或可能不会自动完成错误到期设置。
- 如果包括您在内的任何人对该错误发表评论，则会重置60天的到期时钟。
- 意见：
- 状态“意见”意味着对特定错误存在意见分歧，人们可以自由继续讨论，但项目或软件包维护人员需要转向其他工作并考虑关闭问题。 这个想法是错误可以被标记为封闭，因此开发人员不会浪费时间，但讨论仍然可以进行。
- 这种状态“意见”被认为是一项实验，并将受到密切监控。
- 无效：
- 当错误报告中没有足够的信息来确定它是否是一个错误时，即使已经为记者解决了这个问题，也应该使用此状态。
- 如果报告的问题根本不是错误，也应该使用，例如用户错误
- 它应该保守使用，因为默认搜索中标记为无效的错误不再显示
- 在失效之前，请务必对错误进行三重检查
- 过期：
- 此状态类似于“无效”，但专门针对已完成不完整的错误。 （往上看。）
- 只能使用launchpadlib或电子邮件界面设置此状态。
- 与无效错误一样，过期错误不会显示在默认搜索中。
- 确认 ：
- 另一位记者遇到了同样的错误，这可能是以重复错误或错误评论的forms出现的
- 确认的错误需要原始记者以外的人确认
- 这有助于确保错误一般适用于Ubuntu，而不是记者系统的问题，因此……
- 请不要确认自己的错误！
- 检伤分类：
- UbuntuBugControl的成员认为该报告描述了一个真正的错误，足够详细，开发人员可以开始修复。 （另见下文提示）
- 当您确信开发人员应该查看它并且有足够的信息时，请使用此选项
- 虽然不是必需的，但在任何上游转发发生之前，错误的Ubuntu任务状态将被分类
- 有关Linux的错误Triaged意味着已经使用上游主线内核测试了该错误
- 进行中：
- 如果您正在修复错误，请将其设置为“正在进行”，以便人们知道发生了什么
- 正在进行的错误应该分配给处理它们的人
- 修复已提交：
- Ubuntu bug任务：更改正在等待并很快上传（这是PENDINGUPLOAD在Bugzilla中的内容）
- 当一个更新的软件包存在于一个提议的存储库中时，也会使用Fix Committed，即hardy-proposed
- 将补丁附加到错误时不使用Fix Committed
- 上游错误任务：修复程序在CVS / SVN / bzr中或提交到某个地方
- 修复发布：
- Ubuntu bug任务：修复程序已上传到官方Ubuntu存储库
- 注意：这不包括 – 建议即强硬提议
- 请不要犹豫，将更改日志添加为评论，以便人们知道修复了哪个软件包版本
- 如果在当前开发版本中修复了错误，则修复已发布。 如果还需要在稳定版本中修复错误，请使用“Target to release”链接为该版本指定它。
- 上游错误任务：发布了一个发布tarball并公开发布
- 不会修复：
- 当错误修复太具争议性时，有时会使用此状态
- 它最常用于具有释放目标的错误，该错误不会在该特定版本中修复，但可能会在以后修复
- 它也可以用于开发人员不想实现的function请求
（格式将与维基略有不同，因为此处的格式更有限）
相关问题和解答：
重要性价值： Ubuntu Bugs的重要性价值如何决定