Reviewed-by: Alex Shi <alex.shi@xxxxxxxxxxxxxxxxx> 在 2020/12/8 下午9:16, Ran Wang 写道: > Signed-off-by: Ran Wang <gxndwr@xxxxxxxxxxx> > --- > Change in v2: > - For 'cn_development_coding' part, change back to '是关于编码过程的' > > .../translations/zh_CN/process/1.Intro.rst | 61 ++++++++++--------- > 1 file changed, 32 insertions(+), 29 deletions(-) > > diff --git a/Documentation/translations/zh_CN/process/1.Intro.rst b/Documentation/translations/zh_CN/process/1.Intro.rst > index 10a15f3dc282..f05405d96c51 100644 > --- a/Documentation/translations/zh_CN/process/1.Intro.rst > +++ b/Documentation/translations/zh_CN/process/1.Intro.rst > @@ -11,33 +11,35 @@ > 执行摘要 > -------- > > -本节的其余部分涵盖了内核开发过程的范围，以及开发人员及其雇主在这方面可能遇 > -到的各种挫折。内核代码应该合并到正式的（“主线”）内核中有很多原因，包括对用 > -户的自动可用性、多种形式的社区支持以及影响内核开发方向的能力。提供给Linux > -内核的代码必须在与GPL兼容的许可证下可用。 > +本节的其余部分介绍了内核开发流程相关知识，其中包括开发者及其雇主在这方面可能遇 > +到的各种问题。内核代码合并到官方的（“主线”）仓库会有很多好处，比如能在第一时 > +间让用户获得更新，可以从社区得到多种形式的支持，以及能够以此影响内核未来发展方 > +向。需要注意提供给Linux内核的代码必须是在与GPL兼容的许可证下使用。 > > -:ref:`cn_development_process` 介绍了开发过程、内核发布周期和合并窗口的机制。 > -涵盖了补丁开发、审查和合并周期中的各个阶段。有一些关于工具和邮件列表的讨论。 > -鼓励希望开始内核开发的开发人员作为初始练习跟踪并修复bug。 > +:ref:`cn_development_process` 介绍了内核开发流程、发布周期以及合并窗口期相关的 > +机制。同时还讲解了补丁开发、审查和合并周期各个阶段要点。此外还包括一些关于工具 > +和邮件列表的讨论。我们建议那些希望开始内核开发的开发者们以跟踪并修复bug作为初 > +始练习。 > > > -:ref:`cn_development_early_stage` 包括早期项目规划，重点是尽快让开发社区参与 > +:ref:`cn_development_early_stage` 介绍项目早期的工作规划，重点是尽快让开发社区 > +有机会参与到规划中 > > -:ref:`cn_development_coding` 是关于编码过程的；讨论了其他开发人员遇到的几个 > -陷阱。对补丁的一些要求已经涵盖，并且介绍了一些工具，这些工具有助于确保内核 > -补丁是正确的。 > +:ref:`cn_development_coding` 是关于编码过程的；讨论了一些其他开发者曾经走入到 > +的误区。并介绍社区对补丁的要求，同时指导如何通过使用一些工具来帮助确保内核补 > +丁的质量。 > > -:ref:`cn_development_posting` 讨论发布补丁以供评审的过程。为了让开发社区 > -认真对待，补丁必须正确格式化和描述，并且必须发送到正确的地方。遵循本节中的 > -建议有助于确保为您的工作提供最好的接纳。 > +:ref:`cn_development_posting` 介绍发布补丁以供评审的流程。补丁只有在符合特定的 > +格式及正确描述，并且发送到正确的地方，开发社区才有可能对其认真审查。遵循本节中 > +的建议有助于确保为您的工作成果提供最好的接纳。 > > -:ref:`cn_development_followthrough` 介绍了发布补丁之后发生的事情；该工作 > -在这一点上还远远没有完成。与审阅者一起工作是开发过程中的一个重要部分；本节 > -提供了一些关于如何在这个重要阶段避免问题的提示。当补丁被合并到主线中时， > -开发人员要注意不要假定任务已经完成。 > +:ref:`cn_development_followthrough` 介绍了提交补丁之后发生的事情；至此工作实际 > +上还远未完成。与审阅者一起合作是开发过程中的重要部分；本节提供了一些关于如何在 > +这个重要阶段避免出现问题的提示。此外，即使当补丁已经被合并到主线中，开发者也不 > +能认为任务就此完成。 > > :ref:`cn_development_advancedtopics` 介绍了两个“高级”主题： > -使用Git管理补丁和查看其他人发布的补丁。 > +使用Git管理补丁和查看其他人提交的补丁。 > > :ref:`cn_development_conclusion` 总结了有关内核开发的更多信息，附带有带有 > 指向资源的链接. > @@ -62,19 +64,20 @@ Linux最引人注目的特性之一是这些开发人员可以访问它；任何 > 内核开发周期可以涉及1000多个开发人员，他们为100多个不同的公司 > （或者根本没有公司）工作。 > > -与内核开发社区合作并不是特别困难。但是，尽管如此，许多潜在的贡献者在尝试做 > -内核工作时遇到了困难。内核社区已经发展了自己独特的操作方式，使其能够在每天 > -都要更改数千行代码的环境中顺利运行（并生成高质量的产品）。因此，Linux内核开发 > +与内核开发社区合作并不是特别困难。但是，尽管如此，许多潜在的贡献者在尝试参与 > +内核开发时遇到了困难。内核社区已经发展了自己独特的开发流程，使其能够在每天 > +都要更改数千行代码的环境中顺利运转（并生成高质量的产品）。因此，Linux内核开发 > 过程与专有的开发方法有很大的不同也就不足为奇了。 > > -对于新开发人员来说，内核的开发过程可能会让人感到奇怪和恐惧，但这个背后有充分的 > -理由和坚实的经验。一个不了解内核社区的方式的开发人员（或者更糟的是，他们试图 > -抛弃或规避内核社区的方式）会有一个令人沮丧的体验。开发社区, 在帮助那些试图学习 > -的人的同时，没有时间帮助那些不愿意倾听或不关心开发过程的人。 > +对于新开发者来说，内核的开发流程可能会让人感到陌生和望而生畏，但这个背后其实 > +是有充分的理由和坚实的实际经验作支撑。一个不了解内核社区工作方式的开发者（或 > +者更糟的是，如果他们试图抛弃或规避内核社区的方式）将会有一个令人沮丧的体验。 > +毕竟开发社区在帮助那些试图学习的人的同时，没有时间帮助那些不愿意倾听或不关心 > +开发流程的人。 > > -希望阅读本文的人能够避免这种令人沮丧的经历。这里有很多材料，但阅读时所做的 > -努力会在短时间内得到回报。开发社区总是需要能让内核变更好的开发人员；下面的 > -文本应该帮助您或为您工作的人员加入我们的社区。 > +希望大家能通过阅读本文来避免那些令人沮丧的经历。这里有很多材料，请相信阅读这 > +些所付出的努力将会在短时间内得到回报。开发社区总是需要那些能让内核变更好的 > +开发者；下面的文章应当能帮助您或为您工作的人加入我们的社区。 > > 致谢 > ---- >
