Documentation/translations/zh_CN/process/6.Followthrough.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/process/6.Followthrough.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_CN/process/6.Followthrough.rst
Extension
.rst
Size
11009 bytes
Lines
158
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. include:: ../disclaimer-zh_CN.rst

:Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`

:Translator:

 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>

:校译:

 吴想成 Wu XiangCheng <bobwxc@email.cn>

.. _cn_development_followthrough:

跟进
====

此时，您已经遵循了到目前为止给出的指导方针，并且，随着您自己的工程技能的增加，
已经发布了一系列完美的补丁。即使是经验丰富的内核开发人员也能犯的最大错误之一
是，认为他们的工作现在已经完成了。事实上，发布补丁意味着进入流程的下一个阶段，
可能还需要做很多工作。

一个补丁在首次发布时就非常出色、没有改进的余地，这是很罕见的。内核开发流程已
认识到这一事实，因此它非常注重对已发布代码的改进。作为代码的作者，您应该与
内核社区合作，以确保您的代码符合内核的质量标准。如果不参与这个过程，很可能会
无法将补丁合并到主线中。

与审阅者合作
------------

任何意义上的补丁都会导致其他开发人员在审查代码时发表大量评论。对于许多开发
人员来说，与审阅人员合作可能是内核开发过程中最令人生畏的部分。但是如果你
记住一些事情，生活会变得容易得多：

 - 如果你已经很好地解释了你的补丁，审阅人员会理解它的价值，以及为什么你会
   费尽心思去写它。但是这个并不能阻止他们提出一个基本的问题：在五年或十年后
   维护含有此代码的内核会怎么样？你可能被要求做出的许多改变——从编码风格的
   调整到大量的重写——都来自于对Linux的理解，即从现在起十年后，Linux仍将
   在开发中。

 - 代码审查是一项艰苦的工作，这是一项相对吃力不讨好的工作；人们记得谁编写了
   内核代码，但对于那些审查它的人来说，几乎没有什么长久的名声。因此，审阅
   人员可能会变得暴躁，尤其是当他们看到同样的错误被一遍又一遍地犯下时。如果
   你得到了一个看起来愤怒、侮辱或完全冒犯你的评论，请抑制以同样方式回应的冲动。
   代码审查是关于代码的，而不是关于人的，代码审阅人员不会亲自攻击您。

 - 同样，代码审阅人员也不想以牺牲你雇主的利益为代价来宣传他们雇主的议程。
   内核开发人员通常希望今后几年能在内核上工作，但他们明白他们的雇主可能会改
   变。他们真的，几乎毫无例外地，致力于创造他们所能做到的最好的内核；他们并
   没有试图给雇主的竞争对手造成不适。

 - 请准备好应对看似“愚蠢”的代码风格修改请求，以及将部分代码拆分到内核
   共享模块的要求。维护者的职责之一是保持整体风格的一致性。有时这意味着，
   你在驱动中为解决某一问题而采用的巧妙取巧方案，实际上需要被提炼为通用的
   内核特性，以便未来复用。

所有这些归根结底就是，当审阅者向您发送评论时，您需要注意他们正在进行的技术
评论。不要让他们的表达方式或你自己的骄傲阻止此事。当你在一个补丁上得到评论
时，花点时间去理解评论人想说什么。如果可能的话，请修复审阅者要求您修复的内
容。然后回复审阅者：谢谢他们，并描述你将如何回答他们的问题。

请注意，您不必同意审阅者建议的每个更改。如果您认为审阅者误解了您的代码，请
解释到底发生了什么。如果您对建议的更改有技术上的异议，请描述它并证明您对该
问题的解决方案是正确的。如果你的解释有道理，审阅者会接受的。不过，如果你的
解释证明缺乏说服力，尤其是当其他人开始同意审稿人的观点时，请花些时间重新考虑
一下。你很容易对自己解决问题的方法视而不见，以至于你没有意识到某些东西完全
是错误的，或者你甚至没有解决正确的问题。

Andrew Morton建议，每一个不会导致代码更改的审阅评论都应该产生一个额外的代码
注释；这可以帮助未来的审阅人员避免第一次出现的问题。

Annotation

Implementation Notes