LWN：把GitHub加到kernel开发工作流程里！-技术圈

关注了就能看到更多这么棒的文章哦～

Pulling GitHub into the kernel process

By Jake Edge
June 23, 2021
DeepL assisted translation
https://lwn.net/Articles/860607/

近来相关开发者正在努力让内核的开发流程能更加 "现代化"。目前为止的重点是提供更好的工具来简化大家常用的基于电子邮件的工作流程。但是，"基于电子邮件" 这个方式，对一些潜在的贡献者来说是感到不满的，特别是那些可能只是想提交一个小小的 bug fix、而对在本地搭建完整工作流程丝毫不感兴趣的人。用于项目托管的那些 "forge（锻造）" 网站，比如 GitHub 和 GitLab，就为这种类型的一次性贡献工作提供了一个尽量简便的提交方式，但这些网站与 mainline kernel 的主要开发工作并不匹配，这是事实。不过，有一些正在进行的工作可能会改变这一切。

Linux 基金会的 Konstantin Ryabitsev 一直在带头进行这项工作，这至少可以追溯到他在 2019 年 9 月提出的 better kernel tooling 草案。这些想法在 2019 年的内核维护者峰会（2019 Kernel Maintainers Summit）和 10 月份的 2019 年欧洲开源峰会（Open Source Summit Europe 2019）的会议上进行了讨论。自始至终，Ryabitsev 一直在研究如何使那些不愿意使用电子邮件的 patch 提交者有更加便利的提交方式。在这个过程中，他还发布了用于收集 patch 的 b4 tool，并且致力于确保 patch 来源证实（patch attestation）。

最近在 kernel workflows mailing list 中的一封邮件介绍了在开发一个自动化机器人（bot）方面取得了一些进展，该 bot 可以将 GitHub 的拉动请求（PR，pull request）变成一组格式很不错的 patch，并发送给正确的 review 人员和邮件列表。"这是一个单向操作，可以有效地将 Github 变成 'git-send-email' 的一个很不错的替代品。" 他还阐述了这个 bot 可以为内核维护者和 patch 作者提供的一些好处：

patch 作者不再需要摸索熟悉 git-format-patch、get_maintainer.pl 和 git-send-email 等工具了，也不需要有一个适合发送 patch 的邮件网关（mail gateway）来正确提交 patch 了
内核各个子系统的维护者可以配置实施他们想要的任何 CI pre-check（我们可以开发提供一组 Github action 的 library，所以大家不需要每个人都来重复调用 checkpatch.pl），只有通过的 patch 才会被发送给他们。
bot（最终）应该足够聪明，可以自动跟踪 v1..vX 的各个版本 pull request，如果 API 可以直接使用的话。

他暂时不确定 bot 是否应该集中在一个单一的 git 仓库（当然每个 forge 平台网站都可以有一个）作为单一的提交点，或者子系统维护者也许想自己来配置一个 git 仓库。后者就可以让维护者来自己设置自己特有的 check 标准（类似 checkpatch.pl 这种），但这意味着他们也要自己去对 git 仓库进行一些管理工作了。

此外，Ryabitsev 还想知道大家希望在什么时候来关闭 PR，以及如何关闭。bot 可以监控 mainline，一旦一组 patch 被合入了就自动关闭 PR，但这显然不是最完美的方案。对他来说，一个更简便的方法是 "在 pull request 被发送到邮件列表之后立即自动关闭这个 PR，并附上 '谢谢你，后续流程请关注你的电子邮箱' 这样的信息"，但他不确定这是否是最好的方案。

正如人们可以预料到的情况，参与这个讨论的人的反馈非常热烈。虽然内核社区内在很多领域缺乏多样性，但事实上关于开发工作流程的意见通常来说总是各种各样的。有一些维护者对于这个工作完全没有兴趣。正如 Christoph Hellwig 所说。"请把我维护的所有子系统从这个垃圾功能中排除在外。我最不需要的就是那些无法采用正常工作流程的人的 patch。"

Jiri Kosina 也赞同 Hellwig 的意见，他们的意见可能更多的是与那些使用 GitHub（和类似的系统）的人的期望相关，而不是针对 web-based 内核开发工作方式。Dmitry Vyukov 问道，如果 Hellwig 和 Kosina 都无法识别出来某组 patch 是通过哪种流程提交到 mailing list 里来的，那么为什么他们不愿意接受这个系统提供的 patch？Vyukov 说，他目前就遇到了一个 Git 通过邮件提交的问题，他对解决这个问题毫无兴趣，因此他可以理解其他人为什么可能也会有类似的想法。此外，他也看到了这种 bot 的好处：

换个角度来说，这种工作流程可能可以确保你永远不需要提醒 patch 作者来运行 checkpatch.pl 了，也不需要花时间来针对代码格式提出 review 意见，也不需要重新 review 第二版 patch，因为代码格式检查会被强制执行，还有很多类似的好处。所以我认为这个方案对维护者来说实际上是有利的。

Hellwig 并不反对 web-based 解决方案，但是他不想与 GitHub 扯上任何关系。但 Ryabitsev 似乎并不希望 "重新实现很多我们已经可以从 Github 和其他类似网站 '免费' 获得的功能 "。Mark Brown 和 Laurent Pinchart 都表示，GitHub 的通常做法跟内核社区的做法无法匹配。其中 Pinchart 指出在 GitHub 上不能对 patch 的 commit message 提出意见，这通常会导致出现写的不好的 commit message。该平台在一定程度上来说是在培训这些开发者这么做：

那些只接触过这类平台的开发者很可能从来没有认识到 commit message 的重要性，也没有学习过如何把一个功能恰当地分割成多个 commit。这些都是这类平台固有的问题，我们很可能需要以自动化的方式来处理（至少在某种程度上要处理掉），否则维护者会被逼疯了的[…]。

但 Miguel Ojeda 认为，这跟新加入的开发者首次在邮件列表中提交 patch 的情况其实没有什么区别。"同样的情况也正发生在 LKML 中——有些人写了不合适的 commit message，但我们会去纠正他们，他们也就学会了"。他还指出，自动对 patch 进行的检查可以帮助到开发者和维护者：

[……]这对于教导新人以及节省维护者花在解释工作上的时间特别有用。哪怕维护者自己可能有一套电子邮件模板来处理这些常见情况，他们也还是需要花费时间，用了这个 bot 之后维护者甚至都不会见到这种邮件了。

Ojeda 正在进行 Rust for Linux 项目，我们在四月份的时候就介绍过这个项目。他说他也一直在开发一个 bot：

在 Rust for Linux 开发中，我就有一个 GitHub bot，它会对 PR 进行 review 并指出 commit message 中的常见错误（tag、格式、lkml vs.lore links，诸如此类的问题）。目前为止，它在教新人如何遵循内核开发流程方面非常有效。
我还在继续扩展它，希望能处理好 Acks、Reviewed-by、Tested-by 等等，然后只有在带上这个 patch 的 CI 通过之后才会进行合入（这个 CI 测试包括在 QEMU 下运行 test，对代码格式的检查，还有语法 lints 等）。

但是 Ojeda 想倡导的是一个与 Ryabitsev 的设想有不少差异的方向。Ojeda 想把 patch review 等工作的主要场地从邮件列表转移到 GitHub。他还在考虑让他的 bot 从邮件列表中挑选 patch 并将其转化为 GitHub 的 PR，这与 Ryabitsev 的做法正相反。

Ryabitsev 则对此评论说："这种做法很酷，但我基于神学理由反对这样做:) " 具体来说，他担心的是在内核开发过程中发生基础设施的 "单点故障（single point of failure）" 问题。如果他的机器人因为某些原因无法使用了，可能会给希望使用这个 bot 的人带来不便，但这不会阻碍 kernel 的开发工作。他认为 GitHub 只是作为一个 "开发者前端工具（developer frontend tool）"。

与 Ojeda 的意图有些类似，Brendan Higgins 也有一个工具可以从邮件列表（具体来说是 kselftest 的邮件列表）中提取 patch 并上传到一个 Gerrit 服务中去。他认为他的 bot 可能可以和 Ryabitsev 正在研究的 bot 进行一些配合。同样地，Drew DeVault 也一直在进行这类反方向的工作，也就是从邮件列表提取 patch 送到 project forge 的网站。Patchwork 项目，是一个存在很久的代码审查项目，它也在从邮件列表中收集 patch 来放到 web application 里展示。看起来，大部分人的主要目标是让 patch 脱离邮件列表，但这并不是 Ryabitsev 期望的方向。

虽然有些维护者不想参与到这个 "带有 GitHub 的未来流程" 中去，但其他维护者却对它将会带来的可能性充满热情。Vyukov 认为，拥有一个带有多个分支的 GitHub 仓库，这将有助于巩固内核开发的整体局面，目前内核开发在各个子系统中都是分散开发的。他认为这是一个统一编码风格标准的机会。他认为最终使用哪种风格并不重要，"重要的是代码风格在整个项目中要是一致的"。这也将会使得整个代码 tree 上进行的测试也都是一致的，并且开发流程也是一致的：

这可能是第一次，我们将有可能对开发流程写出合适的文档（目前的每个子系统都有的各有差异的规则，因为通常只与单个子系统有关的东西的 RoI [投资回报率] 较低，所以通常不会写在文档里）。

目前还不清楚 Vyukov 对整个代码树的一致性的这个需求是否得到了广泛的认同，但一直以来，确实有人都在抱怨难以适应不同的子系统的工作流程和提交要求。此外，也有人希望能让这这种快速的、一次性的贡献工作变得更容易一些，正如 Ryabitsev 所说：

我们的代码 review 流程也必须要更好地支持那些合理的 "错别字修改" 的 patch。目前，这对普通人来说都是过于繁重的负担，因为一个 15 分钟的工作突然变成了一个需要付出艰巨努力的工作。这个 bot 的目标是使这类顺手做的（drive-by） patch 更容易得以提交，而不会将维护者埋没在一堆质量很差的 patch 之中。

显然，非常有必要将 "junk submission" （质量很差的提交）尽量减少。Linus Torvalds 说，他不得不关闭 GitHub 的电子邮件通知，因为它有太多的信息。人们显然在注册到某个项目中成为成员之前，没有经过仔细选择和检查。除此之外，任何一种来自 PR 的 patch 要提交的话都需要进行一些 sanity check，比如限制 patch size，这样 Ryabitsev 指出的那种 PR (https://github.com/torvalds/linux/pull/779, 一个恶作剧修改了 kernel 中几万个文件的 PR) 就不会真的出现在邮件列表中。

这种 PR 指出了另一个问题：Git 仓库的维护问题。Greg Kroah-Hartman 说，这样就需要一直留意（mointor）所有用于此目的的 Git 仓库。这不是一个小任务：

无论是放在哪个 Git 仓库，都需要不断地维护，从而保持它得到及时更新、并处理掉会积累在那里的众多 PR、以及处理掉明显的垃圾邮件和代码仓库被滥用的问题，在知名的 Git 仓库里这种问题总是会出现很多。

Torvalds 不希望他自己 GitHub 仓库被用在这个目的上，Kroah-Hartman 也不愿意。而无论如何，必须有人负责保持 Git 代码库的整洁，这是 "一项吃力不讨好的（thankless）任务，还需要持续不断地努力工作"。但 Ryabitsev 希望今后 Linux 基金会可以资助这种工作，如果确有必要的话。

最后，这个工作可能会完全依赖于 GitHub bot 能达到什么样的无缝配合程度。如果维护者真的无法从任何有实质意义的角度来区分出这类 patch，那么大多数维护者应该不会拒绝其中修复了真正 bug 的完善 patch。然而，这种理想情况可能不是会很快实现的，这很可能会导致这个实验早早结束。很期待未来的几个月或几年里事情会怎样发展。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～