Documentation/translations/zh_CN/process/5.Posting.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/process/5.Posting.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_CN/process/5.Posting.rst
Extension
.rst
Size
15069 bytes
Lines
254
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/5.Posting.rst <development_posting>`

:Translator:

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

:校译:

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

.. _cn_development_posting:

发布补丁
========

您的工作迟早会准备好提交给社区进行审查，并最终包含到主线内核中。毫不稀奇，
内核开发社区已经发展出一套用于发布补丁的约定和过程；遵循这些约定和过程将使
参与其中的每个人的生活更加轻松。本文档试图描述这些约定的部分细节；更多信息
也可在以下文档中找到
:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`。

何时寄送
--------

在补丁完全“准备好”之前，避免发布补丁是一种持续的诱惑。对于简单的补丁，这
不是问题。但是如果正在完成的工作很复杂，那么在工作完成之前从社区获得反馈就
可以获得很多好处。因此，您应该考虑发布正在进行的工作，甚至维护一个可用的Git
树，以便感兴趣的开发人员可以随时赶上您的工作。

当发布中有尚未准备好被包含的代码，最好在发布中说明。还应提及任何有待完成的
主要工作和任何已知问题。很少有人会愿意看那些被认为是半生不熟的补丁，但是
那些愿意的人会带着他们的点子来一起帮助你把工作推向正确的方向。

创建补丁之前
------------

在考虑将补丁发送到开发社区之前，有许多事情应该做。包括：

 - 尽可能地测试代码。利用内核的调试工具，确保内核使用了所有可能的配置选项组合
   进行构建，使用交叉编译器为不同的体系结构进行构建等。

 - 确保您的代码符合内核代码风格指南。

 - 您的更改是否具有性能影响？如果是这样，您应该运行基准测试来显示您的变更的
   影响（或好处）；结果的摘要应该包含在补丁中。

 - 确保您有权发布代码。如果这项工作是为雇主完成的，雇主对这项工作具有所有权，
   并且必须同意根据GPL对其进行发布。

一般来说，在发布代码之前进行一些额外的思考，几乎总是能在短时间内得到回报。

补丁准备
--------

准备补丁发布的工作量可能很惊人，但在此尝试节省时间通常是不明智的，即使在短期
内亦然。

必须针对内核的特定版本准备补丁。一般来说，补丁应该基于Linus的Git树中的当前
主线。当以主线为基础时，请从一个众所周知的发布点开始——如稳定版本或 -rc
版本发布点——而不是在一个任意的主线分支点。

也可能需要针对-mm、linux-next或子系统树生成版本，以便于更广泛的测试和审查。
根据补丁的区域以及其他地方的情况，针对其他树建立的补丁可能需要大量的工作来
解决冲突和处理API更改。

只有最简单的更改才应格式化为单个补丁；其他所有更改都应作为一系列逻辑更改进行。
分割补丁是一门艺术；一些开发人员花了很长时间来弄清楚如何按照社区期望的方式来

Annotation

Implementation Notes