6. 跟进
到目前为止，您已经遵循了迄今为止给出的指南，并且凭借自己的工程技能，发布了一系列完美的补丁。即使是经验丰富的内核开发人员也可能犯的最大错误之一是认为他们的工作现在已经完成。事实上，发布补丁标志着进入下一个阶段的过程，可能还有相当多的工作要做。
很少有补丁在第一次发布时就达到了完美，没有改进的余地。内核开发过程认识到了这一事实，因此严重倾向于改进已发布的代码。作为代码的作者，您将被期望与内核社区合作，以确保您的代码符合内核的质量标准。如果您不参与这个过程，很可能会阻止您的补丁被合并到主线。
6.1. 与审阅者合作
任何重要的补丁都会引起其他开发人员的评论。与审阅者合作对许多开发人员来说可能是内核开发过程中最令人生畏的部分。但是，如果您记住以下几点，生活会变得轻松得多：
-
如果您解释了您的补丁，审阅者将理解其价值以及您为什么要费心编写它。但是，这个价值并不能阻止他们提出一个根本性的问题：在五到十年后维护带有这些代码的内核会是什么样子？您可能会被要求做出许多更改，从代码风格的微调到重大重写，都是基于对 Linux 在未来十年仍将存在并处于开发中的理解。
-
代码审查是一项艰苦的工作，而且相对来说是一项不太受人赞赏的工作；人们会记得谁编写了内核代码，但对于那些审查代码的人来说，几乎没有什么持久的名声。因此，审阅者可能会变得暴躁，特别是当他们一遍又一遍地看到同样的错误时。如果您收到了看起来愤怒、侮辱性或直接冒犯的审查意见，抵制以同样的方式回应的冲动。代码审查是关于代码的，而不是关于人，代码审查者并不是在攻击您个人。
-
同样地，代码审查者并不是在以牺牲您的利益为代价来推动他们雇主的议程。内核开发人员通常期望未来几年还在内核上工作，但他们明白他们的雇主可能会改变。他们几乎毫无例外地致力于创建尽可能好的内核；他们并不是在试图为他们雇主的竞争对手制造不适。
-
为看似愚蠢的代码风格更改请求和要求将您的代码分解为内核的共享部分做好准备。维护者的一项工作是保持事物看起来一样。有时候这意味着您驱动程序中的巧妙技巧实际上需要成为一个为下一次准备好的通用内核特性。
所有这些归结为，当审阅者给您发送评论时，您需要注意他们所做的技术观察。不要让他们的表达方式或您自己的自尊心阻止这一点。当您收到有关补丁的审查意见时，花时间理解审阅者试图表达的意思。如果可能的话，修复审阅者要求您修复的问题。并回复审阅者：感谢他们，并描述您将如何回答他们的问题。
请注意，您不必同意审阅者建议的每一个更改。如果您认为审阅者误解了您的代码，请解释实际情况。如果您对建议的更改有技术上的异议，请描述并证明您解决问题的解决方案。如果您的解释是合理的，审阅者会接受它们。但如果您的解释没有说服力，特别是如果其他人开始同意审阅者，那么请花些时间重新考虑一下。很容易被自己对问题的解决方案所蒙蔽，以至于您没有意识到某些事情根本出了问题，或者您可能根本没有解决正确的问题。
Andrew Morton 建议说，每一个审查意见如果没有导致代码更改，就应该导致额外的代码注释；这可以帮助未来的审阅者避免第一次出现的问题。
一个致命的错误是忽视审查意见，希望它们会消失。它们不会消失。如果您重新发布代码而没有回应之前收到的评论，您很可能会发现您的补丁毫无进展。
说到重新发布代码：请记住，审阅者不会记得您上次发布的代码的所有细节。因此，提醒审阅者先前提出的问题以及您如何处理这些问题总是一个好主意；补丁变更日志是这类信息的一个好地方。审阅者不应该不得不搜索列表存档来熟悉上次说了什么；如果您帮助他们有一个良好的开端，当他们重新审查您的代码时，他们会心情更好。
如果您尝试做了一切正确的事情，但事情仍然没有进展怎么办？大多数技术分歧可以通过讨论解决，但有时候某人必须做出决定。如果您真诚地认为这个决定对您不利，您总是可以尝试向更高层级的权力申诉。截至目前，这个更高层级的权力往往是 Andrew Morton。Andrew 在内核开发社区中享有很高的声誉；他经常能够解决那些看起来无望的情况。当然，向 Andrew 申诉不应该轻率行事，并且在探索了所有其他替代方案之后才应该这样做。请记住，当然，他可能也不会同意您。
6.2. 接下来会发生什么
如果一个补丁被认为是添加到内核的好东西，并且一旦大部分审查问题已经解决，下一步通常是进入子系统维护者的树。这是因子系统维护者的方式各不相同；每个维护者都有自己的做事方式。特别是，可能会有不止一个树 - 一个用于下一个合并窗口计划的补丁，另一个用于长期工作。
对于没有明显子系统树的领域（例如内存管理补丁），默认树通常最终会成为 -mm。影响多个子系统的补丁也可能通过 -mm 树进行。
进入子系统树可以为补丁带来更高的可见性。现在，与该树一起工作的其他开发人员将默认获得该补丁。子系统树通常也会提供给 linux-next，使其内容对整个开发社区可见。此时，您很有可能会收到来自新一轮审阅者的更多评论；这些评论需要像上一轮一样进行回复。
在这一点上可能会发生的另一件事，取决于您的补丁的性质，是与其他人正在进行的工作发生冲突。在最坏的情况下，严重的补丁冲突可能导致一些工作被搁置，以便将剩余的补丁整合到一起。其他时候，冲突解决将涉及与其他开发人员合作，并且可能将一些补丁在树之间移动，以确保一切都能干净地应用。这项工作可能很痛苦，但请感到幸运：在 linux-next 树出现之前，这些冲突通常只会在合并窗口期间出现，并且必须在匆忙中解决。现在它们可以在合并窗口打开之前悠闲地解决。
如果一切顺利，有一天您会登录并看到您的补丁已经合并到主线内核中。恭喜！庆祝完成后（并且您已经将自己添加到 MAINTAINERS 文件中），请记住一个重要的小事实：工作仍然没有完成。合并到主线会带来自己的挑战。
首先，您的补丁的可见性再次增加。可能会有新一轮来自之前不知道这个补丁的开发人员的评论。也许会有诱惑忽略它们，因为您的代码不再有任何合并的问题。然而，请抵制这种诱惑；您仍然需要对有问题或建议的开发人员做出响应。
更重要的是：合并到主线将使您的代码进入更大规模的测试人员手中。即使您贡献了一个尚未可用的硬件驱动程序，您会惊讶地发现有多少人会将您的代码构建到他们的内核中。当然，有了测试人员，就会有 bug 报告。
最糟糕的 bug 报告是回归。如果您的补丁导致回归，您会发现有大量的目光投向您；回归需要尽快修复。如果您不愿意或无法修复回归（并且没有其他人为您修复），您的补丁几乎肯定会在稳定期间被移除。除了抵消您为将补丁合并到主线所做的所有工作之外，由于未能修复回归而导致补丁被移除可能会使您将来更难将工作合并。
在处理任何回归之后，可能还会有其他普通 bug 要处理。稳定期间是修复这些 bug 并确保您的代码在主线内核发布中表现尽可能稳定的最佳机会。因此，请回复 bug 报告，并尽可能修复问题。这就是稳定期间的目的；一旦旧问题得到解决，您就可以开始创建新的酷炫补丁。
请不要忘记，还有其他可能会产生 bug 报告的里程碑：下一个主线稳定发布，当知名发行版采用包含您的补丁的内核版本等。继续回应这些报告是对您工作的基本自豪的问题。如果这不足以激励您，还值得考虑的是，开发社区会记住那些在将代码合并后失去兴趣的开发人员。下次您发布补丁时，他们将以您不会继续维护它的假设来评估它。
6.3. 其他可能发生的事情
有一天，您可能会打开邮件客户端，看到有人给您发送了一份关于您代码的补丁。毕竟，这就是将您的代码公开的好处之一。如果您同意该补丁，您可以将其转发给子系统维护者（确保包含适当的 From: 行，以便正确归属，并添加您自己的签名），或者发送一个 Acked-by: 回复，并让原始作者将其发送上去。
如果您不同意该补丁，请发送一封礼貌的回复，解释原因。如果可能的话，告诉作者需要做出哪些更改才能使补丁对您可接受。对于被代码的作者和维护者反对的补丁，通常会有一定的抵制，但也仅此而已。如果您被视为毫无理由地阻碍良好工作，这些补丁最终将绕过您并进入主线。在 Linux 内核中，没有人对任何代码拥有绝对的否决权。也许除了 Linus。
在非常罕见的情况下，您可能会看到完全不同的东西：另一个开发人员发布了一个不同的解决方案来解决您的问题。在这种情况下，其中一个补丁很可能不会被合并，而“我的先到了”并不被认为是一个令人信服的技术论点。如果别人的补丁取代了您的并进入了主线，那么真正唯一的回应方式就是高兴您的问题得到了解决，并继续您的工作。在这种方式下被推到一边的工作可能会令人伤心和沮丧，但社区将会记住您的反应，而忘记了到底是谁的补丁最终被合并了。