18c2ecf20Sopenharmony_ci.. include:: ../disclaimer-zh_CN.rst 28c2ecf20Sopenharmony_ci 38c2ecf20Sopenharmony_ci:Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>` 48c2ecf20Sopenharmony_ci:Translator: Alex Shi <alex.shi@linux.alibaba.com> 58c2ecf20Sopenharmony_ci 68c2ecf20Sopenharmony_ci.. _cn_development_process_intro: 78c2ecf20Sopenharmony_ci 88c2ecf20Sopenharmony_ci介绍 98c2ecf20Sopenharmony_ci==== 108c2ecf20Sopenharmony_ci 118c2ecf20Sopenharmony_ci执行摘要 128c2ecf20Sopenharmony_ci-------- 138c2ecf20Sopenharmony_ci 148c2ecf20Sopenharmony_ci本节的其余部分涵盖了内核开发过程的范围，以及开发人员及其雇主在这方面可能遇 158c2ecf20Sopenharmony_ci到的各种挫折。内核代码应该合并到正式的（“主线”）内核中有很多原因，包括对用 168c2ecf20Sopenharmony_ci户的自动可用性、多种形式的社区支持以及影响内核开发方向的能力。提供给Linux 178c2ecf20Sopenharmony_ci内核的代码必须在与GPL兼容的许可证下可用。 188c2ecf20Sopenharmony_ci 198c2ecf20Sopenharmony_ci:ref:`cn_development_process` 介绍了开发过程、内核发布周期和合并窗口的机制。 208c2ecf20Sopenharmony_ci涵盖了补丁开发、审查和合并周期中的各个阶段。有一些关于工具和邮件列表的讨论。 218c2ecf20Sopenharmony_ci鼓励希望开始内核开发的开发人员作为初始练习跟踪并修复bug。 228c2ecf20Sopenharmony_ci 238c2ecf20Sopenharmony_ci 248c2ecf20Sopenharmony_ci:ref:`cn_development_early_stage` 包括早期项目规划，重点是尽快让开发社区参与 258c2ecf20Sopenharmony_ci 268c2ecf20Sopenharmony_ci:ref:`cn_development_coding` 是关于编码过程的；讨论了其他开发人员遇到的几个 278c2ecf20Sopenharmony_ci陷阱。对补丁的一些要求已经涵盖，并且介绍了一些工具，这些工具有助于确保内核 288c2ecf20Sopenharmony_ci补丁是正确的。 298c2ecf20Sopenharmony_ci 308c2ecf20Sopenharmony_ci:ref:`cn_development_posting` 讨论发布补丁以供评审的过程。为了让开发社区 318c2ecf20Sopenharmony_ci认真对待，补丁必须正确格式化和描述，并且必须发送到正确的地方。遵循本节中的 328c2ecf20Sopenharmony_ci建议有助于确保为您的工作提供最好的接纳。 338c2ecf20Sopenharmony_ci 348c2ecf20Sopenharmony_ci:ref:`cn_development_followthrough` 介绍了发布补丁之后发生的事情；该工作 358c2ecf20Sopenharmony_ci在这一点上还远远没有完成。与审阅者一起工作是开发过程中的一个重要部分；本节 368c2ecf20Sopenharmony_ci提供了一些关于如何在这个重要阶段避免问题的提示。当补丁被合并到主线中时， 378c2ecf20Sopenharmony_ci开发人员要注意不要假定任务已经完成。 388c2ecf20Sopenharmony_ci 398c2ecf20Sopenharmony_ci:ref:`cn_development_advancedtopics` 介绍了两个“高级”主题： 408c2ecf20Sopenharmony_ci使用Git管理补丁和查看其他人发布的补丁。 418c2ecf20Sopenharmony_ci 428c2ecf20Sopenharmony_ci:ref:`cn_development_conclusion` 总结了有关内核开发的更多信息，附带有带有 438c2ecf20Sopenharmony_ci指向资源的链接. 448c2ecf20Sopenharmony_ci 458c2ecf20Sopenharmony_ci这个文件是关于什么的 468c2ecf20Sopenharmony_ci-------------------- 478c2ecf20Sopenharmony_ci 488c2ecf20Sopenharmony_ciLinux内核有超过800万行代码，每个版本的贡献者超过1000人，是现存最大、最活跃 498c2ecf20Sopenharmony_ci的免费软件项目之一。从1991年开始，这个内核已经发展成为一个最好的操作系统 508c2ecf20Sopenharmony_ci组件，运行在袖珍数字音乐播放器、台式PC、现存最大的超级计算机以及所有类型的 518c2ecf20Sopenharmony_ci系统上。它是一种适用于几乎任何情况的健壮、高效和可扩展的解决方案。 528c2ecf20Sopenharmony_ci 538c2ecf20Sopenharmony_ci随着Linux的发展，希望参与其开发的开发人员（和公司）的数量也在增加。硬件供应商 548c2ecf20Sopenharmony_ci希望确保Linux能够很好地支持他们的产品，使这些产品对Linux用户具有吸引力。嵌入 558c2ecf20Sopenharmony_ci式系统供应商使用Linux作为集成产品的组件，希望Linux能够尽可能地胜任手头的任务。 568c2ecf20Sopenharmony_ci分销商和其他基于Linux的软件供应商对Linux内核的功能、性能和可靠性有着明确的 578c2ecf20Sopenharmony_ci兴趣。最终用户也常常希望修改Linux，使之更好地满足他们的需求。 588c2ecf20Sopenharmony_ci 598c2ecf20Sopenharmony_ciLinux最引人注目的特性之一是这些开发人员可以访问它；任何具备必要技能的人都可以 608c2ecf20Sopenharmony_ci改进Linux并影响其开发方向。专有产品不能提供这种开放性，这是自由软件的一个特点。 618c2ecf20Sopenharmony_ci但是，如果有什么不同的话，内核比大多数其他自由软件项目更开放。一个典型的三个月 628c2ecf20Sopenharmony_ci内核开发周期可以涉及1000多个开发人员，他们为100多个不同的公司 638c2ecf20Sopenharmony_ci（或者根本没有公司）工作。 648c2ecf20Sopenharmony_ci 658c2ecf20Sopenharmony_ci与内核开发社区合作并不是特别困难。但是，尽管如此，许多潜在的贡献者在尝试做 668c2ecf20Sopenharmony_ci内核工作时遇到了困难。内核社区已经发展了自己独特的操作方式，使其能够在每天 678c2ecf20Sopenharmony_ci都要更改数千行代码的环境中顺利运行（并生成高质量的产品）。因此，Linux内核开发 688c2ecf20Sopenharmony_ci过程与专有的开发方法有很大的不同也就不足为奇了。 698c2ecf20Sopenharmony_ci 708c2ecf20Sopenharmony_ci对于新开发人员来说，内核的开发过程可能会让人感到奇怪和恐惧，但这个背后有充分的 718c2ecf20Sopenharmony_ci理由和坚实的经验。一个不了解内核社区的方式的开发人员（或者更糟的是，他们试图 728c2ecf20Sopenharmony_ci抛弃或规避内核社区的方式）会有一个令人沮丧的体验。开发社区, 在帮助那些试图学习 738c2ecf20Sopenharmony_ci的人的同时，没有时间帮助那些不愿意倾听或不关心开发过程的人。 748c2ecf20Sopenharmony_ci 758c2ecf20Sopenharmony_ci希望阅读本文的人能够避免这种令人沮丧的经历。这里有很多材料，但阅读时所做的 768c2ecf20Sopenharmony_ci努力会在短时间内得到回报。开发社区总是需要能让内核变更好的开发人员；下面的 778c2ecf20Sopenharmony_ci文本应该帮助您或为您工作的人员加入我们的社区。 788c2ecf20Sopenharmony_ci 798c2ecf20Sopenharmony_ci致谢 808c2ecf20Sopenharmony_ci---- 818c2ecf20Sopenharmony_ci 828c2ecf20Sopenharmony_ci本文件由Jonathan Corbet撰写，corbet@lwn.net。以下人员的建议使之更为完善： 838c2ecf20Sopenharmony_ciJohannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, 848c2ecf20Sopenharmony_ciJake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, 858c2ecf20Sopenharmony_ciAndrew Morton, Andrew Price, Tsugikazu Shibata, 和 Jochen Voß. 868c2ecf20Sopenharmony_ci 878c2ecf20Sopenharmony_ci这项工作得到了Linux基金会的支持，特别感谢Amanda McPherson，他看到了这项工作 888c2ecf20Sopenharmony_ci的价值并把它变成现实。 898c2ecf20Sopenharmony_ci 908c2ecf20Sopenharmony_ci代码进入主线的重要性 918c2ecf20Sopenharmony_ci-------------------- 928c2ecf20Sopenharmony_ci 938c2ecf20Sopenharmony_ci有些公司和开发人员偶尔会想，为什么他们要费心学习如何与内核社区合作，并将代码 948c2ecf20Sopenharmony_ci放入主线内核（“主线”是由Linus Torvalds维护的内核，Linux发行商将其用作基础）。 958c2ecf20Sopenharmony_ci在短期内，贡献代码看起来像是一种可以避免的开销；仅仅将代码分开并直接支持用户 968c2ecf20Sopenharmony_ci似乎更容易。事实上，保持代码独立（“树外”）是在经济上是错误的。 978c2ecf20Sopenharmony_ci 988c2ecf20Sopenharmony_ci作为说明树外代码成本的一种方法，下面是内核开发过程的一些相关方面；本文稍后将 998c2ecf20Sopenharmony_ci更详细地讨论其中的大部分内容。考虑： 1008c2ecf20Sopenharmony_ci 1018c2ecf20Sopenharmony_ci- 所有Linux用户都可以使用合并到主线内核中的代码。它将自动出现在所有启用它的 1028c2ecf20Sopenharmony_ci 发行版上。不需要驱动程序磁盘、下载，也不需要为多个发行版的多个版本提供支持； 1038c2ecf20Sopenharmony_ci 对于开发人员和用户来说，这一切都是可行的。并入主线解决了大量的分布和支持问题 1048c2ecf20Sopenharmony_ci 1058c2ecf20Sopenharmony_ci- 当内核开发人员努力维护一个稳定的用户空间接口时，内部内核API处于不断变化之中. 1068c2ecf20Sopenharmony_ci 缺乏一个稳定的内部接口是一个深思熟虑的设计决策；它允许在任何时候进行基本的改 1078c2ecf20Sopenharmony_ci 进，并产生更高质量的代码。但该策略的一个结果是，如果要使用新的内核，任何树外 1088c2ecf20Sopenharmony_ci 代码都需要持续的维护。维护树外代码需要大量的工作才能使代码保持工作状态。 1098c2ecf20Sopenharmony_ci 1108c2ecf20Sopenharmony_ci 相反，位于主线中的代码不需要这样做，因为一个简单的规则要求进行API更改的任何 1118c2ecf20Sopenharmony_ci 开发人员也必须修复由于该更改而破坏的任何代码。因此，合并到主线中的代码大大 1128c2ecf20Sopenharmony_ci 降低了维护成本。 1138c2ecf20Sopenharmony_ci 1148c2ecf20Sopenharmony_ci- 除此之外，内核中的代码通常会被其他开发人员改进。令人惊讶的结果可能来自授权 1158c2ecf20Sopenharmony_ci 您的用户社区和客户改进您的产品。 1168c2ecf20Sopenharmony_ci 1178c2ecf20Sopenharmony_ci- 内核代码在合并到主线之前和之后都要经过审查。不管原始开发人员的技能有多强， 1188c2ecf20Sopenharmony_ci 这个审查过程总是能找到改进代码的方法。审查经常发现严重的错误和安全问题。 1198c2ecf20Sopenharmony_ci 这对于在封闭环境中开发的代码尤其如此；这种代码从外部开发人员的审查中获益 1208c2ecf20Sopenharmony_ci 匪浅。树外代码是低质量代码。 1218c2ecf20Sopenharmony_ci 1228c2ecf20Sopenharmony_ci- 参与开发过程是您影响内核开发方向的方式。旁观者的抱怨会被听到，但是活跃的 1238c2ecf20Sopenharmony_ci 开发人员有更强的声音——并且能够实现使内核更好地满足其需求的更改。 1248c2ecf20Sopenharmony_ci 1258c2ecf20Sopenharmony_ci- 当单独维护代码时，总是存在第三方为类似功能提供不同实现的可能性。如果发生 1268c2ecf20Sopenharmony_ci 这种情况，合并代码将变得更加困难——甚至到了不可能的地步。然后，您将面临以下 1278c2ecf20Sopenharmony_ci 令人不快的选择：（1）无限期地维护树外的非标准特性，或（2）放弃代码并将用户 1288c2ecf20Sopenharmony_ci 迁移到树内版本。 1298c2ecf20Sopenharmony_ci 1308c2ecf20Sopenharmony_ci- 代码的贡献是使整个过程工作的根本。通过贡献代码，您可以向内核添加新功能，并 1318c2ecf20Sopenharmony_ci 提供其他内核开发人员使用的功能和示例。如果您已经为Linux开发了代码（或者 1328c2ecf20Sopenharmony_ci 正在考虑这样做），那么您显然对这个平台的持续成功感兴趣；贡献代码是确保成功 1338c2ecf20Sopenharmony_ci 的最好方法之一。 1348c2ecf20Sopenharmony_ci 1358c2ecf20Sopenharmony_ci上述所有理由都适用于任何树外内核代码，包括以专有的、仅二进制形式分发的代码。 1368c2ecf20Sopenharmony_ci然而，在考虑任何类型的纯二进制内核代码分布之前，还需要考虑其他因素。这些包括： 1378c2ecf20Sopenharmony_ci 1388c2ecf20Sopenharmony_ci- 围绕专有内核模块分发的法律问题充其量是模糊的；相当多的内核版权所有者认为， 1398c2ecf20Sopenharmony_ci 大多数仅限二进制的模块是内核的派生产品，因此，它们的分发违反了GNU通用公共 1408c2ecf20Sopenharmony_ci 许可证（下面将详细介绍）。您的作者不是律师，本文档中的任何内容都不可能被 1418c2ecf20Sopenharmony_ci 视为法律建议。封闭源代码模块的真实法律地位只能由法院决定。但不管怎样，困扰 1428c2ecf20Sopenharmony_ci 这些模块的不确定性仍然存在。 1438c2ecf20Sopenharmony_ci 1448c2ecf20Sopenharmony_ci- 二进制模块大大增加了调试内核问题的难度，以至于大多数内核开发人员甚至都不会 1458c2ecf20Sopenharmony_ci 尝试。因此，只分发二进制模块将使您的用户更难从社区获得支持。 1468c2ecf20Sopenharmony_ci 1478c2ecf20Sopenharmony_ci- 对于只支持二进制的模块的发行者来说，支持也更加困难，他们必须为他们希望支持 1488c2ecf20Sopenharmony_ci 的每个发行版和每个内核版本提供一个版本的模块。为了提供相当全面的覆盖范围， 1498c2ecf20Sopenharmony_ci 可能需要一个模块的几十个构建，并且每次升级内核时，您的用户都必须单独升级 1508c2ecf20Sopenharmony_ci 您的模块。 1518c2ecf20Sopenharmony_ci 1528c2ecf20Sopenharmony_ci- 上面提到的关于代码评审的所有问题都更加存在于封闭源代码。由于该代码根本不可 1538c2ecf20Sopenharmony_ci 用，因此社区无法对其进行审查，毫无疑问，它将存在严重问题。 1548c2ecf20Sopenharmony_ci 1558c2ecf20Sopenharmony_ci尤其是嵌入式系统的制造商，可能会倾向于忽视本节中所说的大部分内容，因为他们 1568c2ecf20Sopenharmony_ci相信自己正在商用一种使用冻结内核版本的独立产品，在发布后不需要再进行开发。 1578c2ecf20Sopenharmony_ci这个论点忽略了广泛的代码审查的价值以及允许用户向产品添加功能的价值。但这些 1588c2ecf20Sopenharmony_ci产品也有有限的商业寿命，之后必须发布新版本的产品。在这一点上，代码在主线上 1598c2ecf20Sopenharmony_ci并得到良好维护的供应商将能够更好地占位，以使新产品快速上市。 1608c2ecf20Sopenharmony_ci 1618c2ecf20Sopenharmony_ci许可 1628c2ecf20Sopenharmony_ci---- 1638c2ecf20Sopenharmony_ci 1648c2ecf20Sopenharmony_ci代码是根据一些许可证提供给Linux内核的，但是所有代码都必须与GNU通用公共许可 1658c2ecf20Sopenharmony_ci证（GPLV2）的版本2兼容，该版本是覆盖整个内核分发的许可证。在实践中，这意味 1668c2ecf20Sopenharmony_ci着所有代码贡献都由GPLv2（可选地，语言允许在更高版本的GPL下分发）或3子句BSD 1678c2ecf20Sopenharmony_ci许可（New BSD License, 译者注）覆盖。任何不包含在兼容许可证中的贡献都不会 1688c2ecf20Sopenharmony_ci被接受到内核中。 1698c2ecf20Sopenharmony_ci 1708c2ecf20Sopenharmony_ci贡献给内核的代码不需要（或请求）版权分配。合并到主线内核中的所有代码都保留 1718c2ecf20Sopenharmony_ci其原始所有权；因此，内核现在拥有数千个所有者。 1728c2ecf20Sopenharmony_ci 1738c2ecf20Sopenharmony_ci这种所有权结构的一个暗示是，任何改变内核许可的尝试都注定会失败。很少有实际 1748c2ecf20Sopenharmony_ci的场景可以获得所有版权所有者的同意（或者从内核中删除他们的代码）。因此，特 1758c2ecf20Sopenharmony_ci别是，在可预见的将来，不可能迁移到GPL的版本3。 1768c2ecf20Sopenharmony_ci 1778c2ecf20Sopenharmony_ci所有贡献给内核的代码都必须是合法的免费软件。因此，不接受匿名（或匿名）贡献 1788c2ecf20Sopenharmony_ci者的代码。所有贡献者都需要在他们的代码上“sign off”，声明代码可以在GPL下与内 1798c2ecf20Sopenharmony_ci核一起分发。无法提供未被其所有者许可为免费软件的代码，或可能为内核造成版权 1808c2ecf20Sopenharmony_ci相关问题的代码（例如，由缺乏适当保护的反向工程工作派生的代码）不能被接受。 1818c2ecf20Sopenharmony_ci 1828c2ecf20Sopenharmony_ci有关版权相关问题的问题在Linux开发邮件列表中很常见。这样的问题通常会得到不少 1838c2ecf20Sopenharmony_ci答案，但要记住，回答这些问题的人不是律师，不能提供法律咨询。如果您有关于 1848c2ecf20Sopenharmony_ciLinux源代码的法律问题，那么与了解该领域的律师交流是无法替代的。依靠从技术 1858c2ecf20Sopenharmony_ci邮件列表中获得的答案是一件冒险的事情。 1868c2ecf20Sopenharmony_ci 187