我已经开始参与分类错误。我看到的前四个错误中有三个是关于 Hardy (8.04)。
我应该怎么做来帮助分类不再支持的 Ubuntu 版本的错误？我应该将它们设置为“无效”吗？
我是 Bug Control（更高权限的 Bug 分类小组之一）和 Bug Squad 的成员。我们有针对旧错误分类的特定指南（不包括具有特殊非标准工作流程的非典型、特殊指南错误）
TL;DR：我们对 EOL 错误设置的状态取决于多种因素。
请勿在任何情况下更改已“修复已发布”、“无效”或“无法修复”的错误状态！！！这些错误已经被认为是“关闭的”，你不应该惹他们！
如果错误是“修复已提交”，那么这取决于您在那里做什么 - 尝试查看是否曾经提交过修复，或者标记“不会修复”，因为 EOL 发布。 这里要小心。有时一个版本并不是真的完全 EOL，所以你必须记住这一点（例如 10.04 Server）。
如果已知错误在 EOL 版本发布后修复，我们将不会修复 EOL 版本的错误。
如果错误未确认修复，我们将标记为不完整，并要求拥有最旧支持版本和其他支持版本的人尝试复制错误，并返回报告。如果没有人可以确认，我们可以保持不完整，直到错误自动过期或不会修复错误（如果没有人回复，通常是前者，或者如果人们报告并且无法复制错误，则是后者）。
如果该错误仅影响 Hardy 而没有其他版本，那么我们将不会修复该错误。
在我们标记错误不会修复的任何情况下，我们总是评论解释原因，如果他们发现错误或在受支持的版本中重现，他们应该将状态更改为新（如果没有其他版本系列在错误上）。
在任何情况下，我们都标记为不完整，我们会评论我们为什么这样做，并要求提供额外的任务或信息，并提到该错误将在一段时间不活动后自动关闭并过期。
只有当我们在 EOL 版本上提交了一个新错误时，无效才有意义，然后我们可以将其标记为“无效”或“不会修复”。我们通常为“非错误”错误或针对不存在的包或不在存储库中的东西（例如 PPA 版本等而不是存储库中的版本）保留“无效”。
您最好的选择是遵循分类指南并#ubuntu-bugs在 Freenode IRC 上的频道停留，并从其他错误小组和错误控制成员那里寻求针对每个错误的指南、技巧和建议。
（这已经在我的雷达上有一段时间了......我将通过脚本浏览针对 EOL 发布系列的错误，并在与其他错误控制器检查后几天内通过 Launchpad API 自动关闭它们，并且安全团队和其他团队，以确保它不会影响他们的流程或造成混乱）
| 归档时间： |
|
| 查看次数： |
166 次 |
| 最近记录： |