我开始参与错误分类。我查看的前四个错误中有三个与 Hardy (8.04) 有关。
我应该做什么来帮助分类不再受支持的 Ubuntu 版本的错误？我应该将它们设置为“无效”吗？
答案1
我是 Bug Control（具有较高权限的 Bug 分类小组之一）和 Bug Squad 的成员。我们对旧 Bug 的分类有特定的指导方针（不包括具有特殊非标准工作流程的非典型、特殊指导方针 Bug）
TL;DR：我们在 EOL 错误上设置的状态取决于多种因素。
如果错误状态已经是“修复已发布”、“无效”或“无法修复”，则在任何情况下都不要更改错误状态！这些错误已被视为“已关闭”，您不应再干扰它们！
如果错误是“已提交修复”，那么它取决于您在那里执行的操作 - 尝试查看是否曾经提交了修复，或者标记为“不会修复”，因为 EOL 发布。 这里要小心。有时某个版本并非真正完全 EOL，因此您必须记住这一点（例如 10.04 Server）。
如果已知错误在 EOL 版本发布后才被修复，我们将不会修复 EOL 版本的错误。
如果未确认错误已修复，我们会将错误标记为“未完成”，并要求使用最旧受支持版本和其他受支持版本的人员尝试复制错误并报告。如果没有人可以确认，我们可以将错误标记为“未完成”，直到错误自动过期，或者不会修复错误（如果没有人回复，通常是前者；如果有人报告但无法复制错误，则是后者）。
如果该错误仅影响 Hardy 而不影响其他版本，则我们不会修复该错误。
在任何情况下，如果我们将错误标记为“无法修复”，我们都会发表评论解释原因，并且如果他们发现错误或在受支持的版本中重现该错误，他们应该将状态更改为“新”（如果没有其他发布系列出现该错误）。
在任何情况下，我们都会将其标记为不完整，评论我们这样做的原因并要求额外的任务或信息，并提到该错误将在一段时间不活动后自动关闭并过期。
仅当我们在 EOL 版本中提交了新的错误时，无效才有意义，然后我们可以将其标记为“无效”或“无法修复”。我们通常将“无效”保留给“不是错误”的错误，或针对不存在的软件包或存储库中不存在的内容的错误（例如 PPA 版本等，而不是存储库中的版本）。
最好的办法是遵循分类指南并访问#ubuntu-bugsFreenode IRC 频道，向其他错误小组成员和错误控制成员询问每个错误的指导方针、提示和建议。
（这个问题已经引起了我的注意一段时间了...我将通过脚本检查 EOL 发布系列相关的错误，并在与其他错误控制者、安全团队和其他团队核实后，在几天内通过 Launchpad API 自动关闭所有错误，以确保它不会影响他们的流程或造成混乱）