LWN：更好地管理内核中的regression问题！
关注了就能看到更多这么棒的文章哦～
Better regression handling for the kernel
By Jonathan Corbet
September 19, 2022
Maintainers Summit
DeepL assisted translation
https://lwn.net/Articles/908324/
在 2022 年的 Linux 内核维护者峰会上安排的第一个会议就是由 Thorsten Leemhuis 主持的，计划花半小时专门讨论回归跟踪（regression tracking）。实际讨论的时间比原计划要更长，针对给用户提供一个不会破坏其应用程序的 kernel 这个需求，进行了许多方面的讨论。
Leemhuis 首先说，在中断了几年之后，他已经成功地获得了专项资助，来担当内核的 regression tracker，并且重新开始了这项工作。他开发了一个新的机器人程序，希望能最大限度地减少所需的工作量，并且，他希望能够有效地进行 regression tracking 的同时不给开发者带来额外的负担。理想来说，报告 bug 的人会在他们的报告中加入一些跟这个机器人程序有关的指令信息，之后机器人就会跟踪所有回复内容。当它看到有 patch 包含了指向这个讨论的 Link tag 的时候，就会把该 bug 标记为已解决（resolved）。
他说，这个应用程序（称为 "regzbot"）还刚刚出现，有缺陷和不足之处。它已经达到了对 Linus Torvalds 有用的程度，但对子系统维护者还没有那么多的价值。无论如何，它比人工手动地去跟踪 bug 要好得多。Regzbot 已经发现了那些本来会被漏掉的 regression。他感谢 Meta 所提供的资金使这项工作得以落实。
Jakub Kicinski 注意到，报告出来的许多 bug 都不是由内核变动所引起的；相反，它们是由固件更新等动作所引入的问题而造成的。他想知道报告出来的 bug 中有多少是内核开发者根本无法去 fix 的。
Torvalds 说，他看到很多 regression 在 -rc1 版本之后仍然存在，尽管它们已经被正常报告出来了。有时它们一直要到-rc5 或-rc6 的时候才会被 fix，他觉得这很让人不爽。他说，大部分的延迟，都是由于在等待有人提出合适的 fix 方案，但他希望最好能更果断地把有问题的 patch 给 revert 掉。James Bottomley 说，如果是一个 bug 被 fix 了，那么这个 feature 还是能够进入最终的 kernel 发布版本中的；但是，如果把这个 feature 都 revert 掉了，就必须要等到下一个合并窗口之后才能再次加入了。这为开发者提供了一个明显的激励机制，使得他们坚持去做 fix 而不是 revert。
Bottomley 还提出了有一些 bug fix 导致了 regression 的问题；如果 revert 掉这个 fix，就会恢复到以前有 bug 的情况。Torvalds 说，这种 "fix" 应该立即 revert 掉，但 Bottomley 认为，开发人员应该权衡新旧两种 bug 的严重性，并以此来决定是否 revert 这个导致问题的 fix。
Leemhuis 说，对于人们报告出来的 regression 问题，一个好的方法是立即在 mailing list 中发布一个 revert patch。如果不出意外，这样的 patch 将迫使人们开始讨论这个问题；只要没有进展，那么可以在 "几天后" 合入这个 revert patch。
Integration testing
Torvalds 说，他希望有更多的人来测试 linux-next，这样就尽量减少进入 mainline 的 bug，但 Mark Brown 回答说，linux-next 是一个很难用的测试目标；在 linux-next 发布的 24 小时内，很难完成一套完整的测试。Bottomley 建议为 regression test 创建另一个代码分支。他说，Linux-next 是为集成测试（integration testing）而创建的；它的作用是发现 merge conflict 和编译问题，这些目标它完成得很好。但是，它从来没有被设计来用在 regression 测试之上。
一些开发者说，linux-next 也很难测试，因为它 "总是有问题的"；Ted Ts'o 问为什么会这样。Brown 说，linux-next 内核通常能正常启动，但经常有一些问题在 build 和启动测试中是不会暴露出来的。他说，KernelCI 做了一些 linux-next 的测试，但 Torvalds 指出，这种测试并没有真正包括驱动程序测试。他说，如果有更多的子系统维护者在他们自己的代码树上进行的测试也能在一个集成之后的代码树上进行，那就更好了。
Brown 说，一般来说，运行自动测试系统的人不知道子系统维护者所进行的测试。如果这些信息能够让更多人获取到，那么这些测试人员就可以扩大他们的覆盖范围。不过，Matthew Wilcox 并不相信这一点；他说，我们正在讨论的 regression 其实并不是集成方面的错误。相反，它们只是其他用户偶然发现的 bug。Torvalds 抱怨说，在他的三台机器上，他几乎每次发布都会遇到问题；这表明测试覆盖率还是不够的。
Leemhuis 回到了 regression 问题的讨论，他说，regression 需要太长时间来 fix。他说，维护者们经常把他们的 fix 工作延后到下一个合并窗口；这就导致了 bug 留在了发布的内核版本之中，并导致了合并窗口之后还需要对 stable kernel 进行大量更新。稳定内核的维护者 Greg Kroah-Hartman 说，有很多子系统的维护者在合并窗口期间发出 pull request，然后在下一个开发周期之前一直不再出声。他说，这不是正确的管理 patch 的方式。
他还谈到了自动选择的 patch 在 stable kernel 中造成 regression 的问题。Paolo Bonzini 说，那些担心这个问题的维护者应该在他们的子系统中完全禁用掉这个自动选择功能，而改用手动选择 patch。还有人指出，开发者可以在他们的 Cc: stable 行中加上 "# wait two weeks" 这样的注释，从而让风险较大的 patch 在稳定版发布前有机会沉淀一段时间；似乎很少有维护者知道他们可以这样做。
Leemhuis 说，另一个问题是，维护者有时会消失，不再发声，或者 fix 程序进入了他们的垃圾邮件文件夹里。他还说，前一个开发周期的 regression 问题往往在处理时就不那么急迫了。他说，维护者也可能根本没有注意到一个 patch 是用来 fix 一个 regression 的，他想知道某种特殊的 tag 是否会有帮助。但是大家对新增一个 tag 没有什么兴趣，而是建议应该写出更好的 changelog。
Bugzilla blues
Leemhuis 说，还有一个长期存在的问题，就是 kernel.org 上的这个 Bugzilla 服务。很少有开发者关注它，结果导致那里提交的高质量的 bug report 就被忽略掉了。Rafael Wysocki 是少数几个使用该服务的内核维护者之一，他说他的 bug report 可能有 10% 是通过该途径收到的。Kroah-Hartman 指出，Bugzilla 项目已不再活跃了，所以该代码基本上没有人维护。Torvalds 补充说，没有其他项目使用 bugzilla 了，并建议也许应该把它配置一下，改成向 linux-kernel 邮件列表发送这些 report。
Ts'o 说，他已经在几个子系统中配置成自动发送邮件了。他说，这很 "方便"，因为 lore.kernel.org 这个 archive 服务是一个比 Bugzilla 更好的 comment tracker （评论跟踪工具）。但 Bugzilla 对于他跟踪那些自己可能几个月都无法处理的那些低优先级的 fuzzing report 很有用；它有助于确保这些 report 不会被漏掉。Wysocki 说，Bugzilla 对于需要提供某种二进制文件（如 firmware image）的报告来说也很有用；电子邮件对于这种情况效果并不好。大家普遍认为 Bugzilla 的服务应该被替换掉，但对应该改成什么样没有太多的建议。Leemhuis 建议在寻找替代方案时，先在这个服务上设置一个 warning。
会议基本要结束了，Leemhuis 问到了对已打过其他 patch 的内核（例如那些由发行版提供商所提供的内核）中的 bug report 应该如何应对。目前，他完全靠自己尽量给出判断，大多数与会者似乎认为这是正确做法。Christoph Hellwig 说，一般来说，bug report 应该是由那些对这个 kernel 进行过 patch 修改的人来负责给出的。不过，对于像 Arch、Fedora 和 openSUSE 这样的社区发行版提供方所提供的只打过很少 patch 的内核，可以当作例外。这些 patch 很少会导致问题，而这些用户提供的测试又是很有价值的。
会议的最后，Torvalds 说他发现 Leemhuis 的 regression-tracking 工作很有用。他在发布内核之前会看这些报告，来了解内核的状况如何。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～