LWN：内核开发者的更好的工具！

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

Better tools for kernel developers

By Jonathan Corbet
February 6, 2020

原文来自：https://lwn.net/Articles/811528/

从许多角度来说，Linux kernel这个项目在用的工具都太过时了，远远落后于现代的孩子们经常用的工具。kernel的工作流程在过去几年表现都很好，不过已经有些迹象表明它不会永远保持不变。一直以来都有一些讨论关于如何改善kernel的工作流程，不过基本还没怎么真正动起来。最近新提出的一个名为get-lore-mbox的简单工具可能预示了工作流程的改进会逐渐加速。

kernel项目一直以来都依赖email，这一点让许多人感到很惊奇，觉得它很过时。这也许真的跟kernel社区开发人员的年龄层次有关。许多开发者，尤其是那些重要的maintainer们，都是在那些基于网页的git服务管理网站出现之前就开始做现在的工作了。许多人其实还用过打孔编程的方式，他们中的许多人仍然没有接受文本编辑器的价值。不过，kernel一直依赖emal的真正的原因其实还是因为没有多少其他工具可以用来支撑这么大规模以及多样化的一个社区。

所以，尽管看起来email（这里不是指那些Gmail这类的公司服务）的未来还不是很明确，但是kernel社区后续会有什么替换工具还很不明朗。首先需要能说服开发者们，新工具会让他们更轻松，而不是更麻烦。对于那些非常繁忙的maintainer来说，如果有什么改进方式会让做事情更慢，他们一定不会接受的。

Konstantin Ryabitsev提出的get-lore-tool并不是一个需要大量开发工作的产物，它仅仅有500行左右的Python代码。核心功能很简单：提供某封email的message ID，它会为你从lore.kernel.org下载完整的email thread，生成一个车本地的mbox文件。这个功能本身其实对所有需要了解某个email塔轮的来龙去脉的人都有用，不过它还拥有许多有用的功能：

•  -a 选项，只会下载这个email thread中最核心的那一系列patch文件，排好序并整理好格式，方便直接传递给git am命令。同时在email thread中如果有一些回复里包含有用的tag（例如Acked-by），也会自动加到相应的patch上去。

• -t 选项，可以把那些只回复给这组patch的cover letter的tag都打到这组中所有的patch上面去。

• 如果这个email thread中有多个版本的patch，那么只会保存最新一个版本的patch文件。也可以用 -v 选项来指定要求某个特定版本的patch文件。

• 如果没有提供message ID，此工具可以从标准输入中读入一个email message，提取出message ID。这样在许多邮件阅读软件里面只要按一个键就可以完成所有工作了。

Kernel maintainer经常需要花许多时间来阅读email thread，从中整理patch，打上tag，等等。这个工具一发出来，最早的反馈（也包括在kernel.org内部用户的邮件列表上的反馈）都是说这是他们长久以来一直渴求的工具。仅需要花很短的时间写出这样一个工具，就能省下许许多多的开发者的时间，不过此前一直没人做这件事情。

也许有人好奇这个工具为什么直到现在才出现。其实要想完成这个工作，首先有两个前提条件。其中之一就是要把所有的kernel mailing list的内容都要可靠地存放起来，并且能用一个程序来简单地进行查询。此前一直缺少一个可靠地存放服务，并且没有一个集中式的地方包含所有的kernel相关的list。在这个问题解决之前，get-lore-mbox这种类型的工具也无从查询历史邮件。lore.kernel.org服务就解决了这个问题，目前看来它已经成为了kernel开发流程的一部分，不过其实它也才出现了不到两年。

早在1975年的时候，Fredrick Brooks在他名为Mythical Man-Month（《人月传说》）的书中，断定说一个高效的软件开发团队需要像一个手术团队一样工作，不同的人做完成不同的角色的任务。kernel项目中也有这样的核心“外科大夫”，同时也有许多其他的专家来完成其他工作。Brooks认为每个团队都要有两位秘书，而kernel社区看起来一直没有这样的角色。他还说每个团队都要有位工具专家，专注于创建团队所需的工具。

kernel项目长期以来一直缺少这样的工具专家。甚至没有一个人能把各位maintainer为了方便自己的工作来创建的工具搜集起来，改为适合大家使用的工具。因此，maintainer在日常工作中经常没有一个合适的工具，或者在使用他们自己简单拼凑出来的工具。这样导致社区失去了改善整体开发效率的一些机会。

在自由软件（free-software）世界里，有一个众所周知的秘密：有一部分开发工作得到了许多公司的支持，但还有一些一直没有公司投入进来。kernel里面也有同样的情况，甚至可以说，有许多很急迫的工作，因为看起来并不是某个人导致的问题，因此没有人会花精力来进行响应的开发。对这类问题的忽视，已经引出了许多问题：精疲力尽的开发者用尽方法来利用自己的业余时间开发来确保项目能有进展；许多安全漏洞；缺少测试和文档；缺少整个社区都需要的工具，等等等等。

除非有哪个业界巨头或者组织愿意投入一些精力和资源来解决这类问题。对kernel来说，Linux Foundation就是这样的一个角色。Linux Foundation一直在许多方面对kernel社区进行支持，包括雇佣了一些关键开发者，在2011年kernel.org被攻破之后接手了它的系统维护工作（此前这个工作一直被大家无视了）。最近，Linux Foundation支持了创建并运营lore.kernel.org，也包括get-lore-mbox工具本身。

关于kernel工作流程的讨论已经达成了不少共识，不过在这个领域还有许多工作需要完成。kernel的开发流程和工具在过去多年一直缺乏关注，从某种意义上来说，这也是因为表面上所有一切都还能正常工作。kernel社区在努力把自己运营好，这方面的工作，比起多数项目来说都做得好得多。当kernel社区找到一段时间来专注于改进工具的时候——Git就是一个很好的例子——最终的产物都会在开发社区中产生连锁影响。不过还是需要先让kernel项目的开发流程碰到一些危机、证明它无法良好支持社区运营，才能有动力进行工具的改善。

真希望今后kernel这边的开发流程的大改变能够跳过这个“先遇到危机”的阶段。其实只要能对kernel社区投入足够的支持工作和资源，这一点希望是很有可能实现的。也就意味着，现在Linux Foundation在做的事情不仅不应该停下来，反而应该能变得更加宏大。支持这个开发工作（包括让Linux Foundation的成员公司来支持）将会是Linux Foundation今后能对整个kernel项目进行支持的最好方式。

全文完

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

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

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