Change IDs for kernel patches
By Jonathan Corbet
August 29, 2019
长久以来email已经证明它是kernel开发过程中的主要通讯交流方式了，尽管它还有这样那样的问题。同样的，Git也成为了代码管理领域方面的主要工具。不过这两者之间其实毫无关联，也就是说，没有什么直接的方法能把Git commit和相应的email讨论给关联起来。每次当patch合入repository（代码仓库）的时候，就好像是改头换面重生了一样，过去的一些信息都被抛弃掉了。Doug Anderson近来在ksummit-discuss list上提了个建议，希望能采用像Gerrit类似的change ID方案，从而把kernel patch的这两段完全不同的“人生”关联起来，不过最终得到的反馈并不如他的预期。
Gerrit是一个代码审查系统，因为它需要记录、跟踪某个patch的多个版本，所以它在patch正文里面增加了一个Chagne-Id tag标记。类似这样：
Change-Id: I6a007dfe91ee1077a437963cf26d91370fdd9556
这个tag会自动加入新patch的第一版里面，然后开发者在后续推送新版本的改动的时候都会保留这个tag标记，所以Gerrit就能意识到刚推上来的是之前一个patch的改进版，把它们关联在一起。对Gerrit来说这个tag很有用，不过kernel社区一直没有接受这个方案。Anderson发出了这封长邮件，希望能改变社区的观点，从而允许（甚至是积极鼓励）在patch里面使用change ID。他说：
“简单来说我希望能有个方法来跟踪某个patch在不断修订过程中的多个版本。现在我看下来我们并没有一个可靠方案，而Change-Id提供的方案则很不错。虽然我们可以提出一些新的方案来达到同样的目的（因为Change-Id不是咱们发明的），但是采用Change-Id的话就可以很方便的改善现状。”
Anderson描述的问题其实是确实存在的，包括LWN编辑本人也都日常需要花费大量时间翻查某些patch的旧版本，从而搞清楚这个patch的改进过程，我作证，我就很需要这样的功能。Guenter Roeck抱怨说他必须“不仅分析邮件标题，还要分析patch的内容，做文本的各种模糊查找比较，然后再分析patch的描述信息”，才能确认出来某个patch是否已经被merged（合入了）。看起来社区里面整体来说都是期待能有一个好方法把patch的历史和最终在kernel仓库里面的合入patch能关联起来的。不过，可惜大家达成共识的部分也就到此为止了。
Linus Torvalds很快回复了，拒绝了增加change ID的主意。他给出的理由跟此前拒绝其他类似ID的理由一致：这些ID只有对起初把ID放入patch的人有价值。Gerrit的change ID也只有对那些知道这个patch来自哪个gerrit服务器（并且有权访问）的人才有用。对其他人来说，这只是changelog里面的一个数字而已，干扰大家查看changelog。Torvalds的原话是：“如果change ID不能用来查到想要的东西的话，那就完全没有什么用了，就该从kernel的代码历史中拿掉”。他的回应也意味着，如果能有个ID可以被第三方用来查找出所需内容的话，那就可能可以被他接受。
他也提出了一个建议，能让Gerrit change ID更加有用。就是把它变成一个能让所有公众访问的网络链接，这样任何人都可以根据这个链接看其他的相关信息，包括这个patch的历史改动。Olof Johansson不太喜欢这个主意，他觉得Gerrit服务器如果被关闭的话，这个链接就失效了。Ted Ts'o则回复认为如果担心服务器关闭的话，那么任何网络链接都不可靠，哪怕像bugzilla links（一个bug track系统的链接）这种已经被接受进入kernel changelog的也无法保证避免这种命运。
不过还有一些其他方法可以解决，包括Torvalds最喜欢的主意，也是社区里面看起来获得最多支持的方案：使用patch第一次提出来的时候已经天然拥有的这个ID——发件人的邮件客户端所创建的message ID：
“第一次创建的时候，它可以自己被生成，不需要你做任何事情；第二次发patch的时候，你只需要翻以前邮件查出来这个值就好。
Ta-daa，你就拿到了一个uuid，可以让其他人引用来代表你这一系列的patch，绝对不会有歧义。”
不过，这个ID可能有几种表现形式。其中最常见的一种就是创建一个“Link:"的tag标签，记录下来这个patch发布到公共mailing-list存档服务器（近期应该都是用lore.kernel.org）的链接。这并不是一个什么新的规则，早在2011年H. Peter Anvin的patch就有使用过。使用这个tag的做法并不常见，不过一直在慢慢增加。近期的kernel发布版本里面，含有这个"Link:" tag的patch比例如下：
| Release | Tags | Percent |
|---|---|---|
| 4.18 | 1,413 | 10.6% |
| 4.19 | 1,944 | 13.8% |
| 4.20 | 1,609 | 11.6% |
| 5.0 | 1,778 | 13.9% |
| 5.1 | 1,908 | 14.6% |
| 5.2 | 2,295 | 16.4% |
| 5.3 | 2,614 | 18.4% |
创建这个tag也很简单，完全可以在patch被合入git仓库的时候自动生成。不过它没法解决所有问题，虽然它能关联到patch被发布到mailing list上的版本，不过没法用来查找这个patch的此前版本。通常来说大家都不太愿意在这封邮件里面讨论这个patch的上一个版本，因为这时候大家已经基本达成一致这个patch应该要合入了。其实是要在更早的版本的讨论邮件里面，才有我们想要的信息，就是为什么这个patch要做新的改动。不过kernel开发者极少会把最终版本patch的message ID回复到此前版本的讨论邮件里去。
很多人提出了相应的解决方案，不过主流的解决方案并不是一个全自动的版本。Thomas Gleixner和Christian Brauner在争论如何在发出新版本的时候要包含此前版本讨论时的链接。Gleixner希望只要一个链接指向此前一版本的起始邮件（cover letter）即可，而Brauner希望填上所有旧版本的链接。无论哪种方案，只要开发者有兴趣，都可以根据这些link回溯回去，找到这个patch历史上是如何改动的，也包括当时的所有讨论。
只要形成这样的规范，就能满足Anderson等大多数开发者的需求了。不过，这需要patch的作者来插入这个链接，没人能保证所有patch作者都会这么做。Dmitry Torokhov就认为他不喜欢这么麻烦：
“作为patch提交者，我实在是不在乎这个查找patch历史的工作。可能我会按你们要求的写个cover letter，列出改动过的几版链接，不过我这样做的目的是希望减少争议，能让我的patch尽快合入，仅此而已。”
他认为，开发者都不会喜欢这种额外工作来加上对此前版本的链接。Anderson也觉得“这个建议的可行性基本是0”。这种说法是有道理的，毕竟很难强迫社区里的数千位开发者在自己提交的每一个patch上面都要多做工作。不过没有他们的合作的话，这个方案又走不下去。
因此，最终还是需要提供一些工具，能让人们尽量不要做额外工作。Gleixner介绍了他自己使用Quilt来实现的用法，不过看起来并不是所有开发者觉得都适用的。Joel Fermandes介绍了他打算实现的一个工具，他觉得可能对大家都有点帮助。Greg Kroah-Hartman则觉得这个工具过于复杂了，建议大家干脆每次贴patch的时候都直接回复到上一版本的邮件里面去，不过其他人指出并不是所有邮件工具都能简单做到这一点的。
Ts'o的一段话基本上结束了这个讨论，他说，感兴趣的开发者应该可以去试着实现一个原型了，然后大家可以审查一下代码，理解这些原理，从而“在大家需要每天使用某个工具之前先有个机会来试一下，避免出现那种CIO选来选去选了个Lotus Notes的尴尬境地”。讨论基本到这里暂时结束了，等有人发出工具，能证明是一个良好解决方案的时候，才会有进行下一步的可能。
在那之前，我们都还是需要使用我们的字符串模糊查找比较的方法来查找patch的历史信息。
全文完
LWN文章遵循CC BY-SA 4.0许可协议。
热烈欢迎转载以及基于现有协议修改再创作～
长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～
1470
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
