Linux内核开发指南：邮件沟通与代码提交规范

内核社区与大多数传统软件工程工作环境的另一个不同之处在于，交流是无形的。使用电子邮件和 IRC 作为主要沟通方式的一个好处是，没有基于性别或种族的歧视。Linux 内核工作环境接纳女性和少数群体，因为你所面对的全部就是一个电子邮件地址。国际化的一面也有助于创造公平的竞争环境，因为你无法根据一个人的名字猜测其性别。男性可能叫 Andrea，女性可能叫 Pat。大多数在内核中工作过并表达过意见的女性都有积极的经历。

语言障碍可能会给一些对英语不自信的人带来问题。为了在邮件列表中正确传达想法，可能需要良好的英语掌握能力，因此建议你在发送邮件前检查一下，确保它们在英语中说得通。

Linux 内核社区并不乐于接受一次性丢过来的大块代码。变更需要被适当地引入、讨论，并拆分成细小的独立部分。这几乎与公司习惯的做法完全相反。你的提案还应该在开发过程的早期就引入，这样你就能收到关于你所做工作的反馈。这也让社区感觉你是在与他们合作，而不是仅仅把他们当作你功能的倾倒场。不过，不要一次向邮件列表发送 50 封邮件，你的补丁系列几乎在任何时候都应该少于这个数量。

拆分的原因如下：

小补丁增加了你的补丁被应用的可能性，因为验证其正确性不需要太多时间或精力。一个 5 行的补丁，维护者几乎不用第二眼就能应用。然而，一个 500 行的补丁可能需要数小时来审查正确性（所需时间与补丁大小成指数比例，或类似关系）。

小补丁在出问题时也非常容易调试。逐个回退补丁比在应用一个非常大的补丁（并且弄坏了东西）之后再去剖析它要容易得多。

不仅发送小补丁很重要，在提交之前重写和简化（或简单地重新排序）补丁也很重要。以下是内核开发者 Al Viro 的一个类比：

“想象一位老师批改数学学生的作业。老师不想看到学生在得出解答之前的试错过程。他们想看到最干净、最优雅的答案。好学生知道这一点，绝不会在最终解答之前提交中间过程。

内核开发也是如此。维护者和审查者不想看到解决问题背后的思考过程。他们想看到一个简单而优雅的解决方案。”

在呈现优雅解决方案与和社区合作、讨论未完成工作之间保持平衡可能很有挑战性。因此，在过程早期获取反馈以改进你的工作是有益的，但也要将你的变更保持在小块中，这样即使你的整个任务现在还未准备好被纳入，它们也可能已经被接受。

同时要意识到，提交未完成且将在“以后修复”的补丁是不可接受的。

除了拆分补丁之外，让 Linux 社区知道他们为什么应该添加这个变更也非常重要。新功能必须被证明是必要且有用的。

提交补丁时，要特别注意你在邮件正文中所说的内容。这些信息将成为补丁的 ChangeLog 信息，并会被永久保存供所有人查看。它应该完整地描述补丁，包含：

关于这些应该是什么样子的更多细节，请参阅文档的 ChangeLog 部分：

所有这些事情有时都很难做到。完善这些实践可能需要数年时间（如果真能做到的话）。这是一个持续改进的过程，需要大量的耐心和决心。但不要放弃，这是可能的。许多人以前做到过，而每个人都必须从你现在所处的位置开始。

感谢 Paolo Ciarrocchi 允许“开发流程”（https://lwn.net/Articles/94386/）部分基于他所写的文字，感谢 Randy Dunlap 和 Gerrit Huizenga 提供了部分你应该说和不应该说的事项清单。还要感谢 Pat Mochel、Hanna Linder、Randy Dunlap、Kay Sievers、Vojtech Pavlik、Jan Kara、Josh Boyer、Kees Cook、Andrew Morton、Andi Kleen、Vadim Lobanov、Jesper Juhl、Adrian Bunk、Keri Harris、Frans Pop、David A. Wheeler、Junio Hamano、Michael Kerrisk 和 Alex Shepard 的审阅、评论和贡献。没有他们的帮助，本文档不可能完成。

维护者：Greg Kroah-Hartman greg@kroah.com

© 版权所有 内核开发社区。