如何加入Linux内核开发社区(6)

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。下面是该文章第六章节的中译文。

6、将补丁工作进行到底

此时此刻，你已经遵循了这里到目前为止给出的所有指导原则，并且由于你自己的工程技能，你已经发布一系列完美的补丁。但即使是经验丰富的内核开发者也可能会犯的一个最大的错误是断定他们的工作已经结束。事实上，发布补丁象征着你的工作已经过渡到了开发过程下一个阶段，很可能还有相当多的工作需要去完成。

很少有补丁可以好到在第一次发布后就没有改进余地了。内核开发过程深知这一事实，并且因此重点关注已发布代码的改进。内核开发社区期望作为补丁代码作者的你能够与社区一起工作来保证你的代码可以达到内核的质量标准。如果未能很好地参与到这个过程中将很可能导致你的补丁无法进入到内核主线。

6.1、与评审者一起工作

任何一个有意义的补丁都会引来一些评论，这些评论是其他开发者对你的补丁进行代码评审时得出的。对于许多开发者来说，与评审者一起工作可能是整个内核开发过程中最令人胆颤心惊的环节了。但如果你记住一些事情，你的工作可能会变得轻松许多：

* 如果你对补丁进行了很好地解释，评审者就会理解它的价值以及为何你在创建补丁时遇到了困难。但这些都无法阻止评审者提出一个基础问题：五年或十年后，维护一个合并了这份代码的内核将会是一个什么样子？你可能被要求进行许多改变–从代码风格改进到大量的代码重写–这些改变都基于这样的一种共识：从现在起的十年间，Linux将仍然活着并依旧在开发中。

* 代码评审是一个困难的工作，并且是一个相对费力不讨好的工作；人们会记住谁编写了内核代码，但那些评审代码的人却很少有持久的名声。因此，评审可能会变得脾气暴躁，特别是当他们看到同一个错误被一再地犯的时候。如果你收到一个看似生气、出言不逊或完全无礼的评审意见，那么要抑制住你本能地回复的冲动。代码评审只是针对代码，而不是针对人，并且代码评审者从其个人角度来说并非是要攻击你。

* 同样，代码评审者不会为了推广他们雇主的方案而故意中伤你的方案。内核开发者常常期望能从现在起在内核上工作很多年，但他们深知他们的雇主可能会变化。他们工作的真实目的毫无疑问是为了创造一个他们所能创造的最好的内核；他们不会设法给雇主的竞争对手制造不适。

所有这一切归结起来就是，当评审者发送评论给你时，你需要关注这些技术意见。不要让他们的表达方式或你的傲慢阻碍这个过程的发生。当你收到针对你的补丁的评审意见时，花些时间去理解评审者所表达的意思。如果可能的话，修正那些评审者请求你修正的问题。并且回应评审者：对他们的评审表示感谢，并且说明你将如何回答他们的问题。

请注意，你无需同意每个评审者建议的改变。如果你认为评审者误解了你的代码，那么解释你的代码的真实意图给评审者。如果你对某个建议的改变存在技术上的异议的话，解释你的异议并证明你的问题解决方案。如果你的解释有道理，评审者会接受它们的。但如果你的解释被证明没有说服力，特别是如果其他开发者开始认同那个评审者的意见时，花些时间重新考虑一下吧。你很容易被你自己的问题解决方案所蒙蔽，甚至你可能没有意识到一些事情从根本上就是错误的，或者也许你根本没有解决那个问题。

一个致命的错误是忽略那些评审意见并期望他们能消失。他们不会消失。如果你重新发布的代码没有处理之前收到的评审意见，你很可能会发现你的补丁将无处可去。

谈到重新发布代码：请记住评审者是不会记住你上一轮发布的代码的所有细节的。因此一个好的方法是提醒评审者之前提出的问题以及你是如何处理这些问题的；补丁的变更日志(changelog)是一个用来记录这类信息的很好的地方。评审者不应该非得通过搜索邮件列表的归档才能重新了解到他们上一次所提出的意见；如果你一开始就帮助他们重新了解上次的问题，那么在他们重新评审你的代码时将会有一个更为好的心情。

如果你已经努力尝试做对每件事，但事情依旧无法进行下去怎么办？大多数技术上的异议都可以通过交流讨论解决，但有时候，有人不得不作出决定。如果你的确认为这个决定不应该由你来作出，那么你总是可以尝试向更高一级的开发者寻求帮助。对于本文来说，更高一级的人可能是Andrew Morton。Andrew在内核开发社区十分受尊敬；他常常可以将那些看上去堵塞地毫无希望的情况疏通开来。要记住，他当然也可能不同意你的看法。

6.2、接下来会发生什么

如果一个补丁加入到内核被认为是件好事，且一旦大多数评审意见都已经被解决掉了，接下来的一步通常是进入一个子系统维护者的源码树中。加入的方式因不同子系统而异；每个维护者都有其自己的工作方式。尤其是，可能有不止一个源码树–可能一个专用于为下一个合并窗口的准备的补丁，另一个用与更长期的工作。

对于那些没有适用的子系统源码树(例如内存管理补丁)的补丁来说，默认的源码树常常最终是-mm树。那些对多个子系统有影响的补丁也可能最终提交到-mm树中。

合入子系统源码树后的补丁将会拥有一个更高级别的可见性。现在工作在那颗源码树上的其他开发者将会默认得到这个补丁。子系统树通常也为-mm和 linux-next两个源码树提供补丁，这将使补丁的内容对整个开发社区可见。此时，你很有很可能从一批新的评审者那里获得更多的评审问题；你需要答复这些问题，就像之前的那轮一样。

此时还有可能发生的是与其他开发者所完成的工作的冲突，这取决于你的补丁的性质。最坏的情况下，严重的冲突可能导致一些工作被放在次要的位置，而剩下的补丁可能最终成型并被合并到内核中。其他时间，冲突解决将涉及到与其他开发者一起工作并且可能涉及在源码树间移动补丁以保证所有事情都能按规则地应用。这种工作很可能是一种痛苦，但你应该知足了：在linux-next树出现之前，这些冲突往往只是在合并窗口打开期间出现，你必须尽快处理掉这些冲突。而现在，在合并窗口打开之前开发者可以从容不迫地解决这些冲突。

某天，如果一切顺利，你登录主机并且会看到你的补丁已经被合并到内核主线了。恭喜恭喜！但是，一旦庆祝结束(并且你已经将你自己加入到MAINTAINERS文件)，记住一个重要的事实是值得的，那就是：工作依旧没有结束。合并到内核主线将带来其自己的挑战。

首先，你的补丁的可见性已经再一次增加了。你可能会收到新的一轮评审意见，这些意见来自于那些之前不曾知道你的补丁的开发者们。你很可能忽略这些意见，因为已经没有关于代码合并的问题了。但抵制住这种诱惑；对于那些提出问题或建议的开发者来说，你仍然需要保持处于积极相应的状态。

但更为重要的是：合并到内核主线后你的代码将被更多的测试人员获得。即使你贡献的是一个尚不可用的硬件的驱动程序，你会惊讶于有这么多人将你的代码构建到他们的内核当中。并且当然，哪里有测试人员，哪里就会有bug报告产生。

最坏的bug报告类型是regression。如果你的补丁导致了一个regression，你就会发现有许多双令人不舒服的眼睛在注视着你；regression需要被尽早修复。如果你不情愿或没有能力修复这个regression(并且没有人为你做这件事)，那么在内核稳定期，你的补丁几乎可以肯定会被移除。因无法修复regression而导致补丁被从内核拉出(pull)，除了否定了之前你为补丁进入主线而做的所有工作之外，还很可能大大增加你的后续工作被合并的难度。

在处理完若干regressions之后，可能还有另外一些普通bug需要处理。内核稳定期是修正这些bug以及确保你首次出现在某内核主线版本的代码尽可能的稳定可靠的最好时机。因此，请回答bug报告，并尽可能地修正问题。内核稳定期就是为此而设立的；一旦旧补丁中所有问题都被处理完毕，你就能够开始创建一些绝妙的新补丁了。

不要忘了其他里程碑也可能创建bug报告：下一个主线稳定版发布、当一些重要的发行版生产商得到了包含你的补丁的内核版本等等。继续响应这些报告事关你在工作中的自豪感。然而，如果感到动力不足，这点也是值得考虑一下的：开发社区会记住那些在合并代码后对他们自己的代码失去兴趣的开发者。下次你再发布一个补丁，他们会在你过后不会继续维护它的假定下对该补丁进行评估。

6.3、其他可能发生的事情

有一天，你会打开你的邮件客户端程序并看到某人给你邮寄了一份针对你的代码的补丁。归根结底，这是将你的代码公开发布的好处之一。如果你认同这个补丁，你可以将它转发给子系统维护者(确认包含一个恰当的From:行以保证其归属是正确的，并且增加一个你自己的signoff)，或以一个Acked-by: 回应并让原始发布者发送给上面的维护者。

如果你不认同这个补丁，那么发送一个礼貌的回应并解释你不认同的原因。如果可能的话，告诉作者需要做哪些改动你才会接受该补丁。对于那些被代码作者和维护者抵制的补丁来说，合并是有一定阻力的，不过也就仅此而已。如果你对某杰出的工作的阻止被认为是没有必要的，那么那些补丁最终还是会绕过你并进入主线。在 Linux内核中，没有人拥有代码的绝对否决权，也许除了Linus。

在极少的情况下，你可能会看到完全不同的情况：另外一个开发者针对你的问题发布了一个不同的解决方法。那一刻，两个补丁中的一个将无法被合并，并且"我的是第一个"不被认为是一个令人信服的技术参数。如果某个其他人的补丁代替了你的并进入到了主线，那真的只有一种回应的方式了：为你的问题被解决掉而高兴并继续你的工作。将某人的工作以这种方式丢在一边可能是伤人感情和令人泄气的，但是在忘记了谁的补丁被真正合并了之后，开发社区会记住你的回应。