LWN: kernel Bugzilla的未来计划！
关注了就能看到更多这么棒的文章哦～
A plan for the kernel Bugzilla
By Jake Edge
October 11, 2022
DeepL assisted translation
https://lwn.net/Articles/910740/
针对内核的 Bugzilla，人们在很大程度上来说是不怎么喜欢用的，至少 upstream kernel 中大部分 bug 都不是通过它报出来的。在最近的维护者峰会上，Thorsten Leemhuis 主持的 regression-handling session 上讨论到了 Bugzilla。作为讨论的后续跟踪，Leemhuis 最近在 ksummit-discuss 邮件列表中发布了一些改进 bugzilla.kernel.org 的当前窘境的建议；由此产生的讨论也帮助大家理解了它存在的哪些领域的问题，以及理解了 bugzilla 工具。
Leemhuis 在他的帖子中指出，那些出席峰会的人对 kernel Bugzilla 表达了相当多的抱怨，所以他的目标是提出一些完全不同的 fix 方案，从而让大家都能喜欢用。那次会议上的主要抱怨是，对大多数内核开发者来说，通过电子邮件进行 bug report 的效果更好；还有人担心 Bugzilla 项目目前没有得到很好的维护。他在 Kernel Summit 会议（YouTube 有视频）上关于 regression tracking 这部分也可以看到人们提出许多跟 Bugzilla 相关的问题。但是还有一些内核开发者（以及一些内核子系统）在使用以及依赖着 Bugzilla，所以彻底的 "解决方案" （放弃这个错误报告工具）并不是一个真正可行的选择，尽管它是一种比较流行的观点。
Leemhuis 建议的方法是，明确宣告内核中大多数部分不使用、或不关注提交到 Bugzilla 的内容。在内核 MAINTAINERS 文件的 2500 个条目中，只有 20 个指定了 Bugzilla 为提交 bug 报告的地方；其余的要么指向邮件列表和维护者的电子邮件地址，要么指向了外部 bug 跟踪工具。来自使用者方面的问题之一是，有 "许多 bug 和 regression 报告（甚至是写得非常好的报告！）"从来没有得到开发者的回复，正如他在 4 月份的分析中所显示的那样。他的目标是将这种报告大部分都重定向到正确的地方，或者至少让报告人明白他们报的 bug 很可能被忽略。
他试图把那些看起来像 regression 的 bug 重定向到合适的地方，而且，他指出。"Artem S. Tashkinov 也研究了一些（或者是所有的？）bug 报告，并试图帮助报告者。" 但是 Tashkinov 似乎对未来的道路有很不一样的看法，与该主题中的许多评论者的看法不一致。他建议，与其尽量减少 Bugzilla 的使用，不如扩大其使用范围。最具争议性的观点可能是要求子系统维护者参与，或者至少要求子系统的 bug report 自动发送到相应的邮件列表。此外：
内核 bugzilla 最终必须是 opt-out 的形式（缺省加入），而不是 opt-in（缺省不加入）。说实话，我打算[自动]把所有在过去 6 个月内[提交]过内核的人都添加进来，当然，如果有新的开发者提交 patch 给内核，我也会把他们加进来。当他们开始 讨厌 收到 bugzilla 的邮件时，他们可以随时自己取消订阅。
Tashkinov 指出，Bugzilla 服务是由 Linux 基金会（LF）运行的，这是一个资金充足的组织；"如今的现实情况是没有人认真在改进它（内核 Bugzilla），这是可耻和可悲的现象。" 但是，为 LF 从事 Bugzilla 和 kernel.org 其他部分的基础设施工作的 Konstantin Ryabitsev 指出，Bugzilla 软件目前已经很古老了，而且没有维护者；基础设施团队正在维持它的运行，但可能不会永远能持续下去。他说，LF 有可能资助这一领域的工作，但在内核社区内需要先达成一致来确定最终方案应该是什么样子，"否则我们实际上就是改用一个新的、闪亮的着火了的垃圾箱取代一个老旧的、生锈的垃圾箱"。
Herding bugs
据 Ryabitsev 说，根本的问题在于缺少一个人管理这些错误报告，但这很难解决：
作为一个 bugmaster 是一个吃力不讨好的工作，不管你的工资有多高，都会变得倦怠。每个人都会从两方面对你感到不满：用户因为他们的东西无法正常工作而感到恼火，而维护者则因为你不断把他们拉去跟那些需要与没有能力 apply patch 或者启动定制内核的人进行大量的来回沟通，面对很多问题从而感到恼火。
这导致 Tashkinov 建议全面转向 GitLab，他认为 GitLab 可以解决他和 Ryabitsev 发现的大部分问题。但 Greg Kroah-Hartman 说，这种转换也不是一个真正切实的选项：
这是一个不可行的方案，原因有很多，最重要的是你试图用 "把我们所有的代码托管基础设施转移到一个完全不同的东西上，而这个东西甚至不能提供我们现在已经拥有的基本功能 " 的方法来解决 "我们没有人愿意在 bugzilla 上处理 bug" 的问题。
对不起，这是不可能的，gitlab 不是这里的解决方案。
Ryabitsev 表示赞同。"只要没有人负责处理报进来的 bug，那么就仍然会面临着完全相同的问题"。他还提到了将社区资源移交给一家营利性公司的危险性，该公司可能会在 "被一些$ENTITY_NOBODY_LIKES 吞噬 "后改变了方向。Tashkinov 回答说，他对使用电子邮件和 Bugzilla 来跟踪 bug 提出了一些有说服力的抱怨；电子邮件更难搜索到现有的 bug 报告，更难生成公开的 bug 报告，也不太适用于提供 bug report 或讨论中常见的大型附件（日志文件、配置信息，等等）。Ryabitsev 承认这些问题，但他说，打算采取的方法是不需要全面转变工作流程的：
我们不久前就认识到了这一点，这就是为什么我们的努力方向是在查询基础上的信息订阅（query-based message feeds）。也就是像 lore.kernel.org 和 lei 这样的工具。现在确实还在进行之中，但它不需要什么 "每个人都必须在今天转换工作流程" 方式的统一配合，而且通过让所有内容都容易复制到镜像系统上来避免引入单点故障。
Laurent Pinchart 说，目前的工具不足以跟踪 bug，尽管电子邮件对于 bug 报告本身来说并不可怕。但是工具是一个侧面的问题，因为需要改进的是工作流程。"如果我们不首先改进流程，找到一种分配人员和时间来处理 bug report 的方法，那么改进工具是很没有意义的"。一旦流程建立起来，工具就会出现，"无论是使用 bugzilla 还是其他什么"。
在该主题的另一部分，Pinchart 指出，虽然电子邮件标准可能足以用于错误跟踪，但如今的电子邮件客户端并不能胜任这一任务。同时，一个更好的 bug tracker 实际上并不能解决根本问题：
就像房间里的大象一样清晰的是，大多数维护者都工作过度。如果我没有时间去研究它，那么无论一个 bug report 是以电子邮件的形式直接到达我的邮箱，还是从 bug tracker 中过来的，都不会有什么区别（我甚至认为 bug tracker 在这方面更糟糕：如果我真的没有时间，我更可能会优先回复电子邮件，而不是在网络浏览器中打开一个链接）。
当然也会有一些问题，如 Tashkinov 抱怨的那样，不知道在哪里发送错误报告。Leemhuis 承认这个问题，但指出 "Reporting issues" 文件是解决方案的一部分；无论如何，用户应该按照这些指南来尽量判断一下，然后在相应的渠道发布报告，希望也能引出一些建议来说应该报到什么地方。Tashkinov 说，用户不会阅读该文件的，就算他们读了，也无法遵循其建议。显然，目前的系统并不完美，但是，正如 Ted Ts'o 所指出的，是志愿者们在努力解决这些错误。对于那些需要更好的支持的人，还有其他的选择：
Artem，在我看来，你是希望志愿者能够提供商业级别的支持——而这是不可能发生的。
用户的数量远远超过我们这些开发者，如果有人需要大量的指导，也许他们应该付费购买红帽、Suse、Canonical 或 CIQ 的支持合同。
但 Tashkinov 再次呼吁将开发人员都加入 Bugzilla，以便将这个 bug tracker 变成一个 opt-out 方式的工具，而不是其目前的 opt-in 方式的。正如人们的猜测，这不是一个受欢迎的建议。Kroah-Hartman 称这是 "一个必定可以让很多人立即愤怒地要求把他们的地址添加到过滤器中的方法"。Ryabitsev 说，要求 "高级工程师做一线 QA" 这是错误的方法；虽然 Tashkinov 坚持认为人们很容易取消对 Bugzilla 的订阅，但 Ryabitsev 说，有一个更容易的途径：
请听听实际的维护者的说法，这样做是行不通的，只会导致 Bugzilla 被加入到每个人的邮件屏蔽名单中（这甚至比登录 Bugzilla，找到选项来修改默认的 assignee 等方式更快）。
Tashkinov 报告说，每周在 Bugzilla 中报告的 Bug 大约有二十几个，但他声称，向各种邮件列表报告 Bug 的效果要差得多。Geert Uytterhoeven 指出，mainline 上每天有超过 40 个 bug 被修复（根据 "fixes: "标签来判断），几乎所有的 bug 都是通过邮件列表的途径报出来的，而不是在 Bugzilla 上报告的。
在这个主题中，Tashkinov 至少两次提到了特定的一个内核 Bugzilla issue，作为无法通过邮件列表跟踪和 fix 的 bug 的例子。它花了两年多的时间以及 250 多条回复才最终解决，这是很难通过电子邮件管理的。然而，该 bug report 也很难成为同事合作的典范。bug 追踪工作可能做得更好，但是一些参与者肯定没有感觉到在这一过程中受到了很好的对待。
A way forward
这些都是很难解决的问题，但是最难解决的似乎是缺少一个 bug-triage （bug 分类）人员（或者最好是个团队），至少在一些评论者来说是这样。Leemhuis 表示有兴趣做更多这样的工作（他已经在为 regression 做类似的工作了），尽管他和其他许多人一样都缺乏时间；Slade Watkins 也自愿帮忙。Leemhuis 不认为 Bug 联络员一定是最重要的，因为他认为应该做更多的工作来帮助指导 Bug 报告者创建好的报告，把它们发送到正确的地方。
正如 Leemhuis 在最初的邮件中建议的那样，也有必要给 Bugzilla 问题报告者调整一下期望。他说，不过，这只是针对问题的 "一些创可贴"。Ryabitsev 发布了一个更加雄心勃勃的计划，建立一个 triage team 以及采用更多的自动化。这个计划得到了普遍的赞同，不过 Leemhuis 对今后是否要依靠 Bugzilla 表示怀疑：
你的计划显然意味着我们要进一步投资于一个已经被上游抛弃了的软件，而且它的维护工作已经是越来越多的负担了。这种投资也会进一步增加我们对该软件的依赖性，因为我们要建立依赖它的工作流程。如今做这个工作，真的明智吗？把这些时间和精力花在建立更好的、更适应未来的东西上不是更好吗？
但是 Ryabitsev 说，保持 Bugzilla 在内核工作中的活力实际上可能有助于帮助这个项目复活，实际上还有其他人也在使用它。"红帽公司使用 bugzilla，OpenSuse 也使用 bugzilla，所以如果 bugzilla 平台看起来还活着，那么很有可能有一个资金充足的主流公司将有能力帮助 bugzilla 继续发展下去"。但与此同时，他希望通过使其在很大程度上不要依赖 Web 应用，从而确保面向未来：
我希望让大多数交流都是通过建立好的去中心化的端到端消息传递来进行的，从而不用使用一个要求所有互动都严格通过 web 界面来进行的工具，把自己限制在一个角落里。
另一个选择是雇佣 patchwork 的开发者们来写一个 "bugwork"。
Ryabitsev 的计划有几个步骤，但 "最难的部分是维护一个愿意做 bug triage 工作的团队"。有几个人有兴趣帮忙，所以这就可以起步了。没有人真正抱怨过这条路，Tashkinov 说，它 "看起来很美妙"。这需要一些时间来实现，但似乎确实有一个计划，以一种希望能改善内核 Bugzilla 的方式来 rework，也许能让目前的一些保持怀疑的开发者在接下来的日子里参与其中。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～