LWN：Red Hat 如何在内核开发流程中使用 GitLab！

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

How Red Hat uses GitLab for kernel development

By Jonathan Corbet
October 1, 2021
LPC
DeepL assisted translation
https://lwn.net/Articles/871237/

自由软件的开发世界中有许多社区已经开始拥抱 Git forges 工具了（如 GitHub、GitLab 或 sourcehut 等）。但内核社区却还没有。这里有许多原因，但其中一个经常被人们听到的理由是，这些 Git forge 工具在内核项目这么大的规模下根本无法很好地完成工作。在 2021 年 Linux Plumbers 会议期间的一次内核峰会讨论中，Donald Zickus 和 Parit Bhargava 希望向大家展示 Red Hat 如何将 GitLab 很好地用在支持内核团队的开发工作上。他们说，这些
forge 工具不仅可以用于内核开发，而且转移过去之后可以带来许多好处。

The transition

Zickus 开始演讲，他说 Red Hat 在去年将其内核团队从 "一个基于 Patchwork 的旧服务" 过渡到 GitLab。在这个改动之前，该团队采用的是一个相当传统的、基于电子邮件的工作流程，随着 patch 数量的增加，这个工作流程变得更难管理。红帽公司在 patch review 以及获得相关人员的确认方面有很多严格的规定，而在 patch 不断闯关的过程中，越来越难以跟踪清楚这些 patch 是否已经完成了相关的流程，这里需要许多人工的判断工作。reviewer 不知道他们应该看哪些 patch，而持续集成（CI）系统则是固化关联起来的（was bolted on）。

是时候做出改变了，所以该公司转向了 GitLab。

Bhargava 简要介绍了 Lab 工具，这是 GitLab 中许多功能的一个可以从命令行调用的接口。也许具有讽刺意味的是，这个工具其实是托管在 GitHub 上的。他说很多开发者都喜欢命令行界面。

一般来说，内核维护者往往都有自己的一套脚本。每个维护者的工具都各不相同。有些维护者会检测某些类型的错误，而另一些维护者则不会。GitLab 可以对于 action 来运行脚本，这样一来就可以取代大部分这种定制的检测了，能确保每个 patch 得到处理都是有一致性的，并都正确带有相关的签名，包括（这里显然是强制性的）Bugzilla ID 等。patch 如果在某方面出现问题，就会被标记为需要注意（attention）。

Bhargava 说，电子邮件使得人们很容易对可以对 patch 发表意见。但对于维护者来说，要从大量的信息中筛选出有价值的，就不那么容易了。GitLab 能够将 comment 和 reply 都按 thread 来区分开，全部都是按照 merge request 来组织起来的，这样就使得这一过程更加容易。所有这些都会跟最终那个 " big fat 'approve' button" 关联在一起，共同决定是否允许合并。他说，目前为止他没有再看到有开发者使用基于电子邮件的批准。

upstream 内核会使用 MAINTAINERS 文件来决定应该由谁来 review 某个特定的 patch，这对代码贡献者来说又是一个需要记住的步骤。在 Red Hat 内部，这个过程现在已经自动化了，当一个 merge request 被生成时，维护者和 reviewer 会根据 owners.yaml 文件来自动分配。review 有两类，分别取决于是否需要 reviewer 的批准。有兴趣的开发者可以通过进行注册来获得某个领域的相关改动的通知。

以前，CI 是被添加到基于电子邮件的流程中，跟 patch 的生成过程是分开的。没有人强制要求使用 CI。在新系统中，CI 被直接整合进来。他说，虽然大多数维护者对 CI 系统并没有太多热情，但其实不应该是这样。CI 系统为内核稳定性提供了很多帮助。在为整个内核做的一些 CI 测试中，开发人员甚至不知道当前有测试正在进行。GitLab 使 CI 测试变得更加明确，可见性强。

接下来 Zickus 接着介绍，他说与 GitLab 合作的经历并不是完全顺利的，他们在一段时间内，不断发现各种问题。GitLab 与他们合作解决了这些问题，其中主要是关于 API 和工具的。Red Hat 也有一个专门的小组在处理 GitLab 未能解决的问题。两家公司之间存在的是 "战略伙伴关系"。

当然，还有一些未解决的问题，包括如何管理信任链（chain of trust）：针对内核的 pull request 都需要进行签名。对 pull request 进行更好的记录也会有帮助。不过，这里最大的担忧可能还是 GitLab 可能会成为一个单点故障源。如果该公司被那些对 Red Hat 及其目标有敌意的人收购了怎么办？在这种情况下，从系统中提取所有必要的数据还是比较容易的。Git tree 已经被 mirror 到其他存储了。他们现在有一个脚本，可以从 GitLab 中提取所有的评论，并把它们转到一个 public-inbox 中。

Prarit 在结束准备好的演讲时说，现在还不能 100% 地确定 GitLab 是否是接下来最好的方向，尽管 Red Hat 目前对它的投入相当深入。但他说，Git forge 的方法是值得尝试的。在进行过渡时，会有很多担心，但事实证明那些并不会成为真正的问题。

Discussion

Greg Kroah-Hartman 在讨论开始时（有点开玩笑地）祝贺演讲者将 Gerrit 的所有功能整合到 GitLab 中。但是接下来他问道，使用这样管理方式的 patch 数量到底有多少？Zickus 回答说，他们每三个月会为 RHEL update 来管理 15000 -16000 个 patch。Bhargava 说，当他们两年前坐下来研究 forge 工具时，Gerrit 并没有他们所需要的许多功能，也许后来 Gerrit 已经变得更好了。

Ted Ts'o 说，他最担心的问题是子系统之间的协作。如果关于某一个子系统的所有信息都被孤立出来存放在 GitLab 中，那么其他子系统的开发者就会多了不少麻烦。尤其是相关的讨论内容，比如说 Gerrit 的 comment 只在 Gerrit 里面存在。内核社区可以考虑在 kernel.org 托管一个 GitLab 实例，但这样一来，有些 patch 的 comment 会出现在这里，而另一些则会出现在 mailing list 中。开发者将不得不在两个地方同时搜索来获得完整信息。他说，除非电子邮件能够在开发过程中保持头等公民的地位，否则很难看到一个可行的过渡方案。

Zickus 回答说，Red Hat 现在正在运行一个 email bridge，用来缓解开发人员的过渡阶段碰到的麻烦。不过并不打算作为一个长期的解决方案保留下来。

Konstantin Ryabitsev 说，他对在 kernel.org 上托管一个 forge 服务的方案不感兴趣。在那里托管过 Bugzilla 服务，体验就并不好，基本上已经被遗弃了，但他还不得不继续清理那里积累的垃圾邮件。一旦一个工具被添加进来开始用起来，就几乎不可能进行删除，因为总是不可避免地有几个人会依赖它。所以它就不得不永远被维护着。

不过，一个更大的问题是与茁壮性（robustness）。如果 kernel.org 突然无法访问了，那么内核开发仍可以继续。临时中断一下虽然有点不方便，但不是一个真正的大问题。但是，如果增加一个中心 forge 服务，就有可能造成这样一种情况，即它发生故障的时候任何工作都无法完成。他说，想象一下这样一种情况：有一个影响数十亿设备的 zero-day 漏洞，而攻击者想阻止它被修补。这样一来，攻击像这类中心 forge 服务之类的关键基础设施对他来说就是一个好主意了。如果这种情况下的处理方式是 "退回到电子邮件方案"，那么什么都没有真正得到解决。

Zickus 说 GitLab 被复制（replicated）并存储在谷歌云上，对此 Ryabitsev 回应说谷歌云在俄罗斯和中国等部分地区是无法使用的。他说，依赖一个大型的云服务商并不是一个好的解决方案；另一方面，self-hosting 也带来了自己特有的一些扩展性以及费用问题。Zickus 说，Red Hat 在中国有一个庞大的测试团队，GitLab 在那里运行良好。不过，如果情况发生变化的话，那确实会是比较麻烦的。

Ryabitsev 说他并不反对将子系统转到 forge 服务，只要确保它不会成为 "一个无人关注的讨论位置"。目前，如果基础设施不可用了，那些 "历史记录" 仍然存在于 lore.kernel.org 等网站上。Zickus 说，将相关讨论都自动转发到 public-inbox 确实可以解决一部分问题。他随后总结了这段讨论，认为没有人真正反对使用这个工具，人们只是在担心如何保存那里发生的讨论。

时间不够了，Ts'o 认为这次会议并不代表讨论结束。像 GitLab 这样的 forge 服务指出了我们的未来方向，像自动 CI 测试这样的功能确实是个好主意。

这次演讲的视频可以在 YouTube 上看到。

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

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

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