0001 .. include:: ../disclaimer-zh_CN.rst
0002
0003 :Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
0004
0005 :Translator:
0006
0007 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
0008
0009 :校译:
0010
0011 吴想成 Wu XiangCheng <bobwxc@email.cn>
0012
0013 .. _cn_development_process_intro:
0014
0015 引言
0016 ====
0017
0018 内容提要
0019 --------
0020
0021 本节的其余部分涵盖了内核开发的过程，以及开发人员及其雇主在这方面可能遇到的
0022 各种问题。有很多原因使内核代码应被合并到正式的（“主线”）内核中，包括对用户
0023 的自动可用性、多种形式的社区支持以及影响内核开发方向的能力。提供给Linux内核
0024 的代码必须在与GPL兼容的许可证下可用。
0025
0026 :ref:`cn_development_process` 介绍了开发过程、内核发布周期和合并窗口的机制。
0027 涵盖了补丁开发、审查和合并周期中的各个阶段。还有一些关于工具和邮件列表的讨论？
0028 鼓励希望开始内核开发的开发人员跟踪并修复缺陷以作为初步练习。
0029
0030
0031 :ref:`cn_development_early_stage` 包括项目的早期规划，重点是尽快让开发社区
0032 参与进来。
0033
0034 :ref:`cn_development_coding` 是关于编程过程的；介绍了其他开发人员遇到的几个
0035 陷阱。也涵盖了对补丁的一些要求，并且介绍了一些工具，这些工具有助于确保内核
0036 补丁是正确的。
0037
0038 :ref:`cn_development_posting` 描述发布补丁以供评审的过程。为了让开发社区能
0039 认真对待，补丁必须被正确格式化和描述，并且必须发送到正确的地方。遵循本节中的
0040 建议有助于确保您的工作能被较好地接纳。
0041
0042 :ref:`cn_development_followthrough` 介绍了发布补丁之后发生的事情；工作在这时
0043 还远远没有完成。与审阅者一起工作是开发过程中的一个重要部分；本节提供了一些
0044 关于如何在这个重要阶段避免问题的提示。当补丁被合并到主线中时，开发人员要注意
0045 不要假定任务已经完成。
0046
0047 :ref:`cn_development_advancedtopics` 介绍了两个“高级”主题：使用Git管理补丁
0048 和查看其他人发布的补丁。
0049
0050 :ref:`cn_development_conclusion` 总结了有关内核开发的更多信息，附带有相关资源
0051 链接。
0052
0053 这个文档是关于什么的
0054 --------------------
0055
0056 Linux内核有超过800万行代码，每个版本的贡献者超过1000人，是现存最大、最活跃的
0057 免费软件项目之一。从1991年开始，这个内核已经发展成为一个最好的操作系统组件，
0058 运行在袖珍数字音乐播放器、台式电脑、现存最大的超级计算机以及所有类型的系统上。
0059 它是一种适用于几乎任何情况的健壮、高效和可扩展的解决方案。
0060
0061 随着Linux的发展，希望参与其开发的开发人员（和公司）的数量也在增加。硬件供应商
0062 希望确保Linux能够很好地支持他们的产品，使这些产品对Linux用户具有吸引力。嵌入
0063 式系统供应商使用Linux作为集成产品的组件，希望Linux能够尽可能地胜任手头的任务。
0064 分销商和其他基于Linux的软件供应商切实关心Linux内核的功能、性能和可靠性。最终
0065 用户也常常希望修改Linux，使之能更好地满足他们的需求。
0066
0067 Linux最引人注目的特性之一是这些开发人员可以访问它；任何具备必要技能的人都可以
0068 改进Linux并影响其开发方向。专有产品不能提供这种开放性，这是自由软件的一个特点。
0069 如果有什么不同的话，那就是内核比大多数其他自由软件项目更开放。一个典型的三个
0070 月内核开发周期可以涉及1000多个开发人员，他们为100多个不同的公司（或者根本不
0071 隶属公司）工作。
0072
0073 与内核开发社区合作并不是特别困难。但尽管如此，仍有许多潜在的贡献者在尝试做
0074 内核工作时遇到了困难。内核社区已经发展出自己独特的操作方式，使其能够在每天
0075 都要更改数千行代码的环境中顺利运行（并生成高质量的产品）。因此，Linux内核开发
0076 过程与专有的开发模式有很大的不同也就不足为奇了。
0077
0078 对于新开发人员来说，内核的开发过程可能会让人感到奇怪和恐惧，但这背后有充分的
0079 理由和坚实的经验。一个不了解内核社区工作方式的开发人员（或者更糟的是，他们
0080 试图抛弃或规避之）会得到令人沮丧的体验。开发社区在帮助那些试图学习的人的同时，
0081 没有时间帮助那些不愿意倾听或不关心开发过程的人。
0082
0083 希望阅读本文的人能够避免这种令人沮丧的经历。这些材料很长，但阅读它们时所做的
0084 努力会在短时间内得到回报。开发社区总是需要能让内核变更好的开发人员；下面的
0085 文字应该帮助您或为您工作的人员加入我们的社区。
0086
0087 致谢
0088 ----
0089
0090 本文档由Jonathan Corbet <corbet@lwn.net> 撰写。以下人员的建议使之更为完善：
0091 Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap,
0092 Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson,
0093 Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。
0094
0095 这项工作得到了Linux基金会的支持，特别感谢Amanda McPherson，他看到了这项工作
0096 的价值并将其变成现实。
0097
0098 代码进入主线的重要性
0099 --------------------
0100
0101 有些公司和开发人员偶尔会想，为什么他们要费心学习如何与内核社区合作，并将代码
0102 放入主线内核（“主线”是由Linus Torvalds维护的内核，Linux发行商将其用作基础）。
0103 在短期内，贡献代码看起来像是一种可以避免的开销；维护独立代码并直接支持用户
0104 似乎更容易。事实上，保持代码独立（“树外”）是在经济上是错误的。
0105
0106 为了说明树外代码成本，下面给出内核开发过程的一些相关方面；本文稍后将更详细地
0107 讨论其中的大部分内容。请考虑：
0108
0109 - 所有Linux用户都可以使用合并到主线内核中的代码。它将自动出现在所有启用它的
0110 发行版上。无需驱动程序磁盘、额外下载，也不需要为多个发行版的多个版本提供
0111 支持；这一切将方便所有开发人员和用户。并入主线解决了大量的分发和支持问题。
0112
0113 - 当内核开发人员努力维护一个稳定的用户空间接口时，内核内部API处于不断变化之中。
0114 不维持稳定的内部接口是一个慎重的设计决策；它允许在任何时候进行基本的改进，
0115 并产出更高质量的代码。但该策略导致结果是，若要使用新的内核，任何树外代码都
0116 需要持续的维护。维护树外代码会需要大量的工作才能使代码保持正常运行。
0117
0118 相反，位于主线中的代码不需要这样做，因为基本规则要求进行API更改的任何开发
0119 人员也必须修复由于该更改而破坏的任何代码。因此，合并到主线中的代码大大降低
0120 了维护成本。
0121
0122 - 除此之外，内核中的代码通常会被其他开发人员改进。您授权的用户社区和客户对您
0123 产品的改进可能会令人惊喜。
0124
0125 - 内核代码在合并到主线之前和之后都要经过审查。无论原始开发人员的技能有多强，
0126 这个审查过程总是能找到改进代码的方法。审查经常发现严重的错误和安全问题。
0127 对于在封闭环境中开发的代码尤其如此；这种代码从外部开发人员的审查中获益匪浅。
0128 树外代码是低质量代码。
0129
0130 - 参与开发过程是您影响内核开发方向的方式。旁观者的抱怨会被听到，但是活跃的
0131 开发人员有更强的声音——并且能够实现使内核更好地满足其需求的更改。
0132
0133 - 当单独维护代码时，总是存在第三方为类似功能提供不同实现的可能性。如果发生
0134 这种情况，合并代码将变得更加困难——甚至成为不可能。之后，您将面临以下令人
0135 不快的选择：（1）无限期地维护树外的非标准特性，或（2）放弃代码并将用户迁移
0136 到树内版本。
0137
0138 - 代码的贡献是使整个流程工作的根本。通过贡献代码，您可以向内核添加新功能，并
0139 提供其他内核开发人员使用的功能和示例。如果您已经为Linux开发了代码（或者正在
0140 考虑这样做），那么您显然对这个平台的持续成功感兴趣；贡献代码是确保成功的
0141 最好方法之一。
0142
0143 上述所有理由都适用于任何树外内核代码，包括以专有的、仅二进制形式分发的代码。
0144 然而，在考虑任何类型的纯二进制内核代码分布之前，还需要考虑其他因素。包括：
0145
0146 - 围绕专有内核模块分发的法律问题其实较为模糊；相当多的内核版权所有者认为，
0147 大多数仅二进制的模块是内核的派生产品，因此，它们的分发违反了GNU通用公共
0148 许可证（下面将详细介绍）。本文作者不是律师，本文档中的任何内容都不可能被
0149 视为法律建议。封闭源代码模块的真实法律地位只能由法院决定。但不管怎样，困扰
0150 这些模块的不确定性仍然存在。
0151
0152 - 二进制模块大大增加了调试内核问题的难度，以至于大多数内核开发人员甚至都不会
0153 尝试。因此，只分发二进制模块将使您的用户更难从社区获得支持。
0154
0155 - 对于仅二进制的模块的发行者来说，支持也更加困难，他们必须为他们希望支持的
0156 每个发行版和每个内核版本提供不同版本的模块。为了提供较为全面的覆盖范围，
0157 可能需要一个模块的几十个构建，并且每次升级内核时，您的用户都必须单独升级
0158 这些模块。
0159
0160 - 上面提到的关于代码评审的所有问题都更加存在于封闭源代码中。由于该代码根本
0161 不可得，因此社区无法对其进行审查，毫无疑问，它将存在严重问题。
0162
0163 尤其是嵌入式系统的制造商，可能会倾向于忽视本节中所说的大部分内容；因为他们
0164 相信自己正在商用一种使用冻结内核版本的独立产品，在发布后不需要再进行开发。
0165 这个论点忽略了广泛的代码审查的价值以及允许用户向产品添加功能的价值。但这些
0166 产品的商业寿命有限，之后必须发布新版本的产品。在这一点上，代码在主线上并得到
0167 良好维护的供应商将能够更好地占位，以使新产品快速上市。
0168
0169 许可
0170 ----
0171
0172 代码是根据一些许可证提供给Linux内核的，但是所有代码都必须与GNU通用公共许可
0173 证（GPLV2）的版本2兼容，该版本是覆盖整个内核分发的许可证。在实践中，这意味
0174 着所有代码贡献都由GPLv2（可选地，语言允许在更高版本的GPL下分发）或3子句BSD
0175 许可（New BSD License，译者注）覆盖。任何不包含在兼容许可证中的贡献都不会
0176 被接受到内核中。
0177
0178 贡献给内核的代码不需要（或请求）版权分配。合并到主线内核中的所有代码都保留
0179 其原始所有权；因此，内核现在拥有数千个所有者。
0180
0181 这种所有权结构也暗示着，任何改变内核许可的尝试都注定会失败。很少有实际情况
0182 可以获得所有版权所有者的同意（或者从内核中删除他们的代码）。因此，尤其是在
0183 可预见的将来，许可证不大可能迁移到GPL的版本3。
0184
0185 所有贡献给内核的代码都必须是合法的免费软件。因此，不接受匿名（或化名）贡献
0186 者的代码。所有贡献者都需要在他们的代码上“sign off（签发）”，声明代码可以
0187 在GPL下与内核一起分发。无法提供未被其所有者许可为免费软件的代码，或可能为
0188 内核造成版权相关问题的代码（例如，由缺乏适当保护的反向工程工作派生的代码）
0189 不能被接受。
0190
0191 有关版权问题的提问在Linux开发邮件列表中很常见。这样的问题通常会得到不少答案，
0192 但请记住，回答这些问题的人不是律师，不能提供法律咨询。如果您有关于Linux源代码
0193 的法律问题，没有什么可以代替咨询了解这一领域的律师。依赖从技术邮件列表中获得
0194 的答案是一件冒险的事情。
0195
