在 Focal Fossa 测试周期间，我发现一个与 Bay Trail、声卡 chtmax98090 上的内部声音无法正常工作相关的错误，我报告了此错误（#1871306）。
我的沟通交流恰好只是通过自动化程序，我提供了所要求的所有详细信息和报告。
此后再没有任何沟通，该错误的状态仍保持不变。
最近，由于 alsa-project 的改进，我测试了该错误的修复程序，并在错误报告中添加了一条评论来解释它。
我应该做什么才能使修复程序得到评估并用于修复该错误？
我注意到在相同的架构/声卡上类似的错误已被忽略并且仍然未解决。
答案1
这不是关于 bug 的问题被忽略。这是关于有限数量的志愿者对这些错误进行分类。
从根本上来说，内核开发人员需要知道的是：
- 错误的优先级。导致系统崩溃和数据丢失的问题排在首位。
- 哪个项目应该负责修复该错误。如果 Alsa 的下一个版本已经修复了该错误，Ubuntu 就不会浪费精力重新修复它。
- 该错误可能位于内核代码的哪个位置。
为了达到这一点，必须分类当内核团队错误分类员查看错误报告时，仍有许多问题。错误报告中可以回答的问题越多，错误分类的可能性就越大。如果分类员必须自己进行所有这些研究，错误就会等到他们想做的时候（记住：志愿者）。如果分类员无法重现问题或缺少正确的硬件，错误就会等到其他人出现。
这个漏洞会影响很多人吗？它会导致系统崩溃或丢失数据吗？还是只是让人讨厌？
上游 (debian、alsa、kernel) 是否已报告此错误？他们是否已取得进展？
这是从未工作过的新硬件吗？还是过去工作过（回归）？它可以在类似硬件上复制吗（可重现）？如果是回归，它被二分了吗？
建议的修复只是一种权宜之计吗？还是真正的修复？这个错误真的是代码问题吗？还是设计问题？
现在让我们将其应用于 Ubuntu 特定的内核开发工作流程：
内核开发人员通常专注于下一个Ubuntu 20.10 的发布。他们可以反向移植一些功能添加到旧内核...但这通常是不必要的，因为大多数 LTS 用户应该使用 HWE 来获取更新的内核。
这意味着您应该始终在 Ubuntu 的预发布版本中测试错误。如果未修复，则这是针对 Ubuntu 预发布版本的有效错误报告（并且更有可能更快地进行分类）。
如果它在旧内核中出现问题，但在新内核中修复，则有人已经修复了该错误。这是稳定版本更新要求或反向移植请求。开发人员可能会拒绝低优先级的请求，因为无论如何，较新的（修复）内核都会在下一个版本中出现在 LTS 中。
发布周期截止时间：Ubuntu20.10 内核冻结几周后就会修复。如果到那时还没有修复，您必须在 11 月使用 21.04 重新测试该错误，因为内核团队将转向下一个 Ubuntu 预发布版本。
如果你有兴趣成为志愿者错误分类员，我们永远欢迎新的参与者！