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

1、内核开发过程指南

本文旨在帮助那些在参与开发社区(community)工作过程中遭遇些许挫折的开发人员(以及他们的管理者)。对于那些不是十分熟悉Linux 内核开发(或通常所说的自由软件开发)的开发人员，本文将以一种易于理解的方式记录社区是如何进行开发工作的。虽然这里会提及一些技术资料，但更 多是面向过程的讨论，这些内容不需要你对内核编程有较深入的了解。

1.1、内容大纲

本文后面章节的内容涵盖了内核开发过程以及开发人员及其雇佣者所遇到的各种挫折。本文还列举了诸多内核代码应该被合并(merge)到官方内核 (主线，mainline)的原因，包括对用户自动可用(automatic availability to users)、社区提供各种形式的支持以及对内核开发演进方向的影响力等。被Linux内核采纳的代码必须使用GPL兼容许可证进行授权。

章节2介绍了Linux内核的开发过程，内核发布的周期以及合并窗口(merge window)机制。该章节还涵盖了补丁开发、评审以及合并周期等各种不同阶段。关于一些工具和邮件列表的讨论也包含在该章节中。我们鼓励那些想要开始内 核开发的开发者们去跟踪和修正bug，并以此作为最初阶段的练习。

章节3涵盖了早期阶段的项目规划(early-stage project planning)，并重点强调了开发社区的尽早参与。

章节4中的内容是有关编码过程的；该章节讨论了其他开发人员在开发过程中所遇到的一些陷阱；涵盖了一些对补丁的要求；并介绍了一些用于帮助保证内 核补丁正确性的工具。

章节5谈到了发布补丁评审的过程。为了能让开发社区认真对待发布(post)的补丁，开发者必须对补丁内容进行适当的格式化和描述，并且开发者必 须将补丁发到合适的地方。遵循本章节中的建议可以最大化地提高你的补丁被开发社区接受的可能性。

章节6涵盖了发布补丁后要做的事情；发布补丁那刻离最终完成还差得很远。与评审者的合作是开发过程中的关键环节；这节提供了许多有关如何在这一重 要阶段避免问题的小建议。这里告诫开发者不要想当然的认为当补丁被合并到主线后工作就完成了。

章节7介绍了一些"高级"主题：使用git管理补丁以及评审其他开发人员发布的补丁。

章节8以更多的有关内核开发的信息来源作为结束此文。

1.2、这篇文档是关于什么的

Linux内核是现有最大的并且是最活跃的自由软件项目之一，它拥有600多万行代码以及超过1000名积极贡献者。自从1991年问世以 来，Linux内核已经逐渐演化成一种最佳的操作系统组件，在袖珍数字音乐播放器、桌面个人计算机、现有的超级计算机以及介于个人计算机与超级计 算机之间的所有类型系统上都有Linux内核在运行。它是一种几乎适合所有情况的稳定的、高效的和可伸缩的解决方案。

伴随着Linux内核的发展，希望参与内核开发的开发人员和公司的数量也迎来了一个较大的增长。硬件制造商想要确保Linux可以良好地支持他们 的产品，使得这些产品对Linux用户具有吸引力。那些将Linux作为一个组件集成到它们产品中的嵌入式系统供应商想要Linux能够尽可能地 满足和适合接下来的任务。而产品基于Linux的Linux发行版供应商以及其他软件供应商更是对Linux内核的能力、性能以及可靠性有着明确 的兴趣。最终用户也常常希望通过改变Linux来使得Linux更好地满足他们的需要。

Linux的一个最引入注目的特点就是它对开发者的平易近人；任何具备所需必要的技能的开发者都可以对Linux进行改进，影响Linux的发展 方向。专利产品无法提供这种开放性，这是自由软件开发过程的一个特质。但是，更可能的是，内核要比其他绝大多数自由软件项目更加开放。一个典型的 三个月内核开发周期可能涉及超过来自100多个不同公司的1000多名开发者(或没有受雇佣于任何公司)的开发工作。

在内核开发社区中工作不是特别难。不过，尽管这样，许多潜在的贡献者在尝试进行内核开发工作时都遇到过困难。内核开发社区逐步形成了自己与众不同 的运营方式，这种方式使得Linux内核在每天成千上万行代码被改变的情况下依旧运行顺畅(并且生产出高质量的产品)。因此Linux内核的开发 过程与专利产品的开发方法有着较大区别也就不足为奇了。

对新开发者来说，内核的开发过程可能看上去有些奇怪和咄咄逼人，但是其背后却有着充分的理由和丰富的经验作为支撑。那些不理解内核开发社区工作方 式(或者，更糟糕的是试图无视或规避)的开发者必将经历挫折。内核开发社区会帮助那些主动尝试学习内核开发过程的开发者们，而对那些不听从或不在 乎开发过程的开发者，开发社区的耐心也是有限的。

希望那些读过此篇文章的开发者们都能避免这样的挫折经历。这里虽然有大量资料需要阅读，但用不了多长时间阅读这些资料所付出的努力就会获得回报。 开发社区总是需要那些愿意帮助内核改善的开发者；接下来的内容应该可以帮助你 — 或者那些为你工作的开发者 — 加入到我们的社区。

1.3、贡献

本文由Jonathan Corbet，corbet@lwn.net撰写，并根据James Berry、Alex Chiang、Roland Dreier、Randy Dunlap、Jake Edge、Jiri Kosina、Matt Mackall、Amanda McPherson、Andrew Morton和Jochen VoB等人的评论作了改进。

Linux基金会(Linux Foundation)对这篇文章的撰写提供了支持；特别感谢Amanda McPherson，是她看到了这份努力的价值，并努力使之成为现实。

1.4、将代码合入主线的重要性

一些公司和开发者偶尔也想知道为何他们要这么麻烦地去学习如何参与内核开发社区的工作，并且要将代码合并到主线版本内核(主线版本内核由 Linus Torvalds负责维护，并且被Linux发行商作为基础版本使用)中去。就短期来讲，贡献代码可能看似是一种可避免的开销；并且独立保留代码并直接对 用户提供支持看起来也更加容易。但事情的真相是独立保留代码(树外，out of tree)是一种虚假经济(false economy)。

下面列举一些内核开发过程方面相关的内容，以此说明一下维护离树代码所要付出的代价，其中大部分将在本文后面有更详细的讨论。考虑：

  * 合并到主线内核的代码对所有Linux用户可用。它将自动出现在所有使能它(enable it)的发行版中。你无需考虑驱动盘、下载或支持不同发行版的多个版本的麻烦事；这对于开发者和最终用户而言都是奏效的。代码合入主线版本解决了大量发行 版以及支持的问题。

  * 尽管内核开发者们努力维护一个稳定的对用户空间的接口，但内部的内核API却是不断变化的。内部接口的不稳定性其实是一种蓄意的设计决策；它允许开发者们 随时做出根本性的改进，而这样做的结果将是获得更高质量的代码。不过这样的策略导致的一个结果就是任何离树代码要想和新内核一起工作就必须要有持 续的维护。维护离树代码就需要大量的工作，而这些工作仅仅是为了能让代码正常工作。

    相反，主线中的代码则不需要开发人员去修正那些因API变化而被破坏的代码。因此合并到主线的代码具有更低的维护成本。

  * 除此之外，内核中的代码经常被其他开发人员改进。授权你的用户社区与客户去改进你的产品常常能带来令人惊讶的结果。

  *  内核代码在合入主线前后都要经过评审。无论原开发者的技术水准有多么高超，评审过程总是能找到改进代码的方法。评审过程常常会发现严重bug以及安全问 题。这些结论对那些在封闭环境下开发出来的代码同样是成立的；这样的代码得益于外部开发者们的评审。而未经外部开发者评审的离树代码则是低质量的 代码。

  * 参与内核开发过程是你影响内核开发方向的一种方式。虽然旁观者的抱怨也会被倾听，但积极的开发者发出的声音显然更强健有力-并且他们具备实现这些改变以让 内核更好地满足他们需要的能力。

  * 当你的代码单独维护时，就存在这种可能性：第三方会贡献类似特性的一个不同的实现。一旦出现这种情况，再将你的代码合并到主线将变得更加困难 – 甚至是不可能。那样你就将面临不愉快的选择，(1)要么长期离树维护一个非标准特性，(2)要么放弃你的代码，让你的用户迁移到主线版本。

  * 贡献代码是整个保证开发过程正常运转的基本行为。通过贡献你的代码，你可以为内核添加新功能，提供能力以及那些对其他内核开发者有用的例子。如果你曾为 Linux开发过代码(或正在考虑这么做)，你肯定对这个平台的持续成功十分感兴趣；而贡献代码就是帮助Linux成功的一种最佳方式。

上面的所有论证适用于任何离树内核代码，包括那些专有的或仅以二进制形式提供的代码。不过，在考虑发行任何仅二进制形式(binary- only)内核代码之前，你应该考虑下面一些额外因素：

  * 关于发行专有内核模块的法律条款充其量是模糊不清的；相当多的内核版权持有者认为绝大多数仅二进制模块是内核的衍生产品(derived product)，因此他们的发行版违背了GNU通用公共许可证(GNU General Public License，下面还有更多关于这个许可证的说明)。笔者不是律师，本文中的内容千万不能被视为法律建议。闭源(closed-source)模块真正 的法律地位只能由法院判决决定。但无论如何困扰这些模块的不确定性是存在的。

  * 二进制模块增加了调试内核问题的难度，甚至于大多内核开发人员都不愿尝试。因此仅二进制模块的发行将增加你的用户获得社区支持的难度。

  * 对于仅二进制模块的发行者而言，支持也是更为困难的，他们必须为每个他们想要支持的发行版以及内核版本提供一个模块版本。一个模块需要几十个构建才能全面 覆盖到所有发行版和不同版本的内核，并且你的最终用户每次升级内核后都需要单独升级你的这个模块。

  * 上面所说的有关代码评审的内容对闭源代码而言更加适用。但由于代码不公开，无法被社区评审，因此毫无疑问将有严重问题。

嵌入式系统制造商特别可能被怂恿而忽视本节前面所说的那些内容，因为他们相信他们交付的是一个完备的产品，产品使用的是一个冻结了的内核版本，发 布后不需要再进行更多的开发了。这种说法忽略了被广受赞同的代码评审的价值以及允许最终用户向你的产品中添加能力的价值。但是这些产品的商业生命 周期也都有限，之后必须发布产品的新版本。在这一点上，代码在主线上且维护良好的制造商将占据更好的位置，并且可以更快地推出满足市场的新产品。

1.5、许可证

代码在若干许可证的授权下被贡献到Linux内核中，但所有代码必须与作为Linux内核整体许可证的GNU通用公共许可证版本2(GPLv2) 兼容。实际上，这意味着所有贡献的代码要么遵照GPLv2许可证(可选的，语言允许在更高版本的GPL许可证下发布)，要么遵照三句版BSD许可 证。任何不遵照兼容许可证的贡献代码将不能被内核所接受。

对于贡献到内核中的代码，是不需要进行版权转让的。所有合入主线内核的代码保留其最初的所有权；因此内核目前已经有成千上万个所有者了。

这种所有权结构的一个含义是任何修改内核许可证的尝试是几乎注定会失败的。几乎没有什么实际情况可以得到所有版权所有者的同意(或者将他们的代码 从内核中移除)。因此，在可见的未来，看不到将许可证迁移到GPL版本3的希望。

所有贡献到内核的代码必须是正当的自由软件。因此，来自匿名(或笔名)的贡献者的代码将不会被接受。所有贡献者都被要求在他们的代码上"签别"， 声明代码可与内核一起在GPL许可证下发行。那些没有被其原作者授权为自由软件的代码或存在版权相关问题风险的代码(例如那些从通过反向工程努力 获得的缺少适当保障的代码)将不能被贡献到内核中。

在Linux开发邮件列表中经常看到有关版权事宜相关的问题。这些问题一般不会缺少回答，但大家应该牢记回答这些问题的人不是律师，不能提供法律 建议。如果你有任何与Linux源代码相关的法律问题，你唯一的选择是与熟知这一领域的律师谈谈。依赖从技术邮件列表中获得的答案是一个危险的事情。

挖掘简单现象背后的复杂本质。– Tony Bai^_^