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