162306a36Sopenharmony_ci.. include:: ../disclaimer-zh_CN.rst
262306a36Sopenharmony_ci
362306a36Sopenharmony_ci:Original: :ref:`Documentation/process/5.Posting.rst <development_posting>`
462306a36Sopenharmony_ci
562306a36Sopenharmony_ci:Translator:
662306a36Sopenharmony_ci
762306a36Sopenharmony_ci 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
862306a36Sopenharmony_ci
962306a36Sopenharmony_ci:校译:
1062306a36Sopenharmony_ci
1162306a36Sopenharmony_ci 吴想成 Wu XiangCheng <bobwxc@email.cn>
1262306a36Sopenharmony_ci
1362306a36Sopenharmony_ci.. _cn_development_posting:
1462306a36Sopenharmony_ci
1562306a36Sopenharmony_ci发布补丁
1662306a36Sopenharmony_ci========
1762306a36Sopenharmony_ci
1862306a36Sopenharmony_ci您的工作迟早会准备好提交给社区进行审查,并最终包含到主线内核中。毫不稀奇,
1962306a36Sopenharmony_ci内核开发社区已经发展出一套用于发布补丁的约定和过程;遵循这些约定和过程将使
2062306a36Sopenharmony_ci参与其中的每个人的生活更加轻松。本文档试图描述这些约定的部分细节;更多信息
2162306a36Sopenharmony_ci也可在以下文档中找到
2262306a36Sopenharmony_ci:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
2362306a36Sopenharmony_ci和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`。
2462306a36Sopenharmony_ci
2562306a36Sopenharmony_ci何时寄送
2662306a36Sopenharmony_ci--------
2762306a36Sopenharmony_ci
2862306a36Sopenharmony_ci在补丁完全“准备好”之前,避免发布补丁是一种持续的诱惑。对于简单的补丁,这
2962306a36Sopenharmony_ci不是问题。但是如果正在完成的工作很复杂,那么在工作完成之前从社区获得反馈就
3062306a36Sopenharmony_ci可以获得很多好处。因此,您应该考虑发布正在进行的工作,甚至维护一个可用的Git
3162306a36Sopenharmony_ci树,以便感兴趣的开发人员可以随时赶上您的工作。
3262306a36Sopenharmony_ci
3362306a36Sopenharmony_ci当发布中有尚未准备好被包含的代码,最好在发布中说明。还应提及任何有待完成的
3462306a36Sopenharmony_ci主要工作和任何已知问题。很少有人会愿意看那些被认为是半生不熟的补丁,但是
3562306a36Sopenharmony_ci那些愿意的人会带着他们的点子来一起帮助你把工作推向正确的方向。
3662306a36Sopenharmony_ci
3762306a36Sopenharmony_ci创建补丁之前
3862306a36Sopenharmony_ci------------
3962306a36Sopenharmony_ci
4062306a36Sopenharmony_ci在考虑将补丁发送到开发社区之前,有许多事情应该做。包括:
4162306a36Sopenharmony_ci
4262306a36Sopenharmony_ci - 尽可能地测试代码。利用内核的调试工具,确保内核使用了所有可能的配置选项组合
4362306a36Sopenharmony_ci   进行构建,使用交叉编译器为不同的体系结构进行构建等。
4462306a36Sopenharmony_ci
4562306a36Sopenharmony_ci - 确保您的代码符合内核代码风格指南。
4662306a36Sopenharmony_ci
4762306a36Sopenharmony_ci - 您的更改是否具有性能影响?如果是这样,您应该运行基准测试来显示您的变更的
4862306a36Sopenharmony_ci   影响(或好处);结果的摘要应该包含在补丁中。
4962306a36Sopenharmony_ci
5062306a36Sopenharmony_ci - 确保您有权发布代码。如果这项工作是为雇主完成的,雇主对这项工作具有所有权,
5162306a36Sopenharmony_ci   并且必须同意根据GPL对其进行发布。
5262306a36Sopenharmony_ci
5362306a36Sopenharmony_ci一般来说,在发布代码之前进行一些额外的思考,几乎总是能在短时间内得到回报。
5462306a36Sopenharmony_ci
5562306a36Sopenharmony_ci补丁准备
5662306a36Sopenharmony_ci--------
5762306a36Sopenharmony_ci
5862306a36Sopenharmony_ci准备补丁发布的工作量可能很惊人,但在此尝试节省时间通常是不明智的,即使在短期
5962306a36Sopenharmony_ci内亦然。
6062306a36Sopenharmony_ci
6162306a36Sopenharmony_ci必须针对内核的特定版本准备补丁。一般来说,补丁应该基于Linus的Git树中的当前
6262306a36Sopenharmony_ci主线。当以主线为基础时,请从一个众所周知的发布点开始——如稳定版本或 -rc
6362306a36Sopenharmony_ci版本发布点——而不是在一个任意的主线分支点。
6462306a36Sopenharmony_ci
6562306a36Sopenharmony_ci也可能需要针对-mm、linux-next或子系统树生成版本,以便于更广泛的测试和审查。
6662306a36Sopenharmony_ci根据补丁的区域以及其他地方的情况,针对其他树建立的补丁可能需要大量的工作来
6762306a36Sopenharmony_ci解决冲突和处理API更改。
6862306a36Sopenharmony_ci
6962306a36Sopenharmony_ci只有最简单的更改才应格式化为单个补丁;其他所有更改都应作为一系列逻辑更改进行。
7062306a36Sopenharmony_ci分割补丁是一门艺术;一些开发人员花了很长时间来弄清楚如何按照社区期望的方式来
7162306a36Sopenharmony_ci分割。不过,这些经验法则也许有帮助:
7262306a36Sopenharmony_ci
7362306a36Sopenharmony_ci - 您发布的补丁系列几乎肯定不会是开发过程中版本控制系统中的一系列更改。相反,
7462306a36Sopenharmony_ci   需要对您所做更改的最终形式加以考虑,然后以有意义的方式进行拆分。开发人员对
7562306a36Sopenharmony_ci   离散的、自包含的更改感兴趣,而不是您创造这些更改的原始路径。
7662306a36Sopenharmony_ci
7762306a36Sopenharmony_ci - 每个逻辑上独立的变更都应该格式化为单独的补丁。这些更改可以是小的(如“向
7862306a36Sopenharmony_ci   此结构体添加字段”)或大的(如添加一个重要的新驱动程序),但它们在概念上
7962306a36Sopenharmony_ci   应该是小的,并且可以在一行内简述。每个补丁都应该做一个特定的、可以单独
8062306a36Sopenharmony_ci   检查并验证它所做的事情的更改。
8162306a36Sopenharmony_ci
8262306a36Sopenharmony_ci - 换种方式重申上述准则,也就是说:不要在同一补丁中混合不同类型的更改。如果
8362306a36Sopenharmony_ci   一个补丁修复了一个关键的安全漏洞,又重新排列了一些结构,还重新格式化了代
8462306a36Sopenharmony_ci   码,那么它很有可能会被忽略,从而导致重要的修复丢失。
8562306a36Sopenharmony_ci
8662306a36Sopenharmony_ci - 每个补丁都应该能创建一个可以正确地构建和运行的内核;如果补丁系列在中间被
8762306a36Sopenharmony_ci   断开,那么结果仍应是一个正常工作的内核。部分应用一系列补丁是使用
8862306a36Sopenharmony_ci   “git bisct”工具查找回归的一个常见场景;如果结果是一个损坏的内核,那么将使
8962306a36Sopenharmony_ci   那些从事追踪问题的高尚工作的开发人员和用户的生活更加艰难。
9062306a36Sopenharmony_ci
9162306a36Sopenharmony_ci - 不要过分分割。一位开发人员曾经将一组针对单个文件的编辑分成500个单独的补丁
9262306a36Sopenharmony_ci   发布,这并没有使他成为内核邮件列表中最受欢迎的人。一个补丁可以相当大,
9362306a36Sopenharmony_ci   只要它仍然包含一个单一的 *逻辑* 变更。
9462306a36Sopenharmony_ci
9562306a36Sopenharmony_ci - 用一系列补丁添加一个全新的基础设施,但是该设施在系列中的最后一个补丁启用
9662306a36Sopenharmony_ci   整个变更之前不能使用,这看起来很诱人。如果可能的话,应该避免这种诱惑;
9762306a36Sopenharmony_ci   如果这个系列增加了回归,那么二分法将指出最后一个补丁是导致问题的补丁,
9862306a36Sopenharmony_ci   即使真正的bug在其他地方。只要有可能,添加新代码的补丁程序应该立即激活该
9962306a36Sopenharmony_ci   代码。
10062306a36Sopenharmony_ci
10162306a36Sopenharmony_ci创建完美补丁系列的工作可能是一个令人沮丧的过程,在完成“真正的工作”之后需要
10262306a36Sopenharmony_ci花费大量的时间和思考。但是如果做得好,花费的时间就是值得的。
10362306a36Sopenharmony_ci
10462306a36Sopenharmony_ci补丁格式和更改日志
10562306a36Sopenharmony_ci------------------
10662306a36Sopenharmony_ci
10762306a36Sopenharmony_ci所以现在你有了一系列完美的补丁可以发布,但是这项工作还没有完成。每个补丁都
10862306a36Sopenharmony_ci需要被格式化成一条消息,以快速而清晰地将其目的传达到世界其他地方。为此,
10962306a36Sopenharmony_ci每个补丁将由以下部分组成:
11062306a36Sopenharmony_ci
11162306a36Sopenharmony_ci - 可选的“From”行,表明补丁作者。只有当你通过电子邮件发送别人的补丁时,这一行
11262306a36Sopenharmony_ci   才是必须的,但是为防止疑问加上它也不会有什么坏处。
11362306a36Sopenharmony_ci
11462306a36Sopenharmony_ci - 一行描述,说明补丁的作用。对于在没有其他上下文的情况下看到该消息的读者来说,
11562306a36Sopenharmony_ci   该消息应足以确定修补程序的范围;此行将显示在“short form(简短格式)”变更
11662306a36Sopenharmony_ci   日志中。此消息通常需要先加上子系统名称前缀,然后是补丁的目的。例如:
11762306a36Sopenharmony_ci
11862306a36Sopenharmony_ci   ::
11962306a36Sopenharmony_ci
12062306a36Sopenharmony_ci        gpio: fix build on CONFIG_GPIO_SYSFS=n
12162306a36Sopenharmony_ci
12262306a36Sopenharmony_ci - 一行空白,后接补丁内容的详细描述。此描述可以是任意需要的长度;它应该说明补丁
12362306a36Sopenharmony_ci   的作用以及为什么它应该应用于内核。
12462306a36Sopenharmony_ci
12562306a36Sopenharmony_ci - 一个或多个标记行,至少有一个由补丁作者的 Signed-off-by 签名。标记将在下面
12662306a36Sopenharmony_ci   详细描述。
12762306a36Sopenharmony_ci
12862306a36Sopenharmony_ci上面的项目一起构成补丁的变更日志。写一则好的变更日志是一门至关重要但常常被
12962306a36Sopenharmony_ci忽视的艺术;值得花一点时间来讨论这个问题。当你编写变更日志时,你应该记住有
13062306a36Sopenharmony_ci很多不同的人会读你的话。其中包括子系统维护人员和审查人员,他们需要决定是否
13162306a36Sopenharmony_ci应该合并补丁,分销商和其他维护人员试图决定是否应该将补丁反向移植到其他内核,
13262306a36Sopenharmony_ci缺陷搜寻人员想知道补丁是否导致他们正在追查的问题,以及想知道内核如何变化的
13362306a36Sopenharmony_ci用户等等。一个好的变更日志以最直接和最简洁的方式向所有这些人传达所需的信息。
13462306a36Sopenharmony_ci
13562306a36Sopenharmony_ci在结尾,总结行应该描述变更的影响和动机,以及在一行约束条件下可能发生的变化。
13662306a36Sopenharmony_ci然后,详细的描述可以详述这些主题,并提供任何需要的附加信息。如果补丁修复了
13762306a36Sopenharmony_ci一个缺陷,请引用引入该缺陷的提交(如果可能,请在引用提交时同时提供其 id 和
13862306a36Sopenharmony_ci标题)。如果某个问题与特定的日志或编译器输出相关联,请包含该输出以帮助其他
13962306a36Sopenharmony_ci人搜索同一问题的解决方案。如果更改是为了支持以后补丁中的其他更改,那么应当
14062306a36Sopenharmony_ci说明。如果更改了内部API,请详细说明这些更改以及其他开发人员应该如何响应。
14162306a36Sopenharmony_ci一般来说,你越把自己放在每个阅读你变更日志的人的位置上,变更日志(和内核
14262306a36Sopenharmony_ci作为一个整体)就越好。
14362306a36Sopenharmony_ci
14462306a36Sopenharmony_ci不需要说,变更日志是将变更提交到版本控制系统时使用的文本。接下来将是:
14562306a36Sopenharmony_ci
14662306a36Sopenharmony_ci - 补丁本身,采用统一的(“-u”)补丁格式。使用“-p”选项来diff将使函数名与
14762306a36Sopenharmony_ci   更改相关联,从而使结果补丁更容易被其他人读取。
14862306a36Sopenharmony_ci
14962306a36Sopenharmony_ci您应该避免在补丁中包括与更改不相关文件(例如,构建过程生成的文件或编辑器
15062306a36Sopenharmony_ci备份文件)。文档目录中的“dontdiff”文件在这方面有帮助;使用“-X”选项将
15162306a36Sopenharmony_ci其传递给diff。
15262306a36Sopenharmony_ci
15362306a36Sopenharmony_ci上面提到的标签(tag)用于描述各种开发人员如何与这个补丁的开发相关联。
15462306a36Sopenharmony_ci:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
15562306a36Sopenharmony_ci文档中对它们进行了详细描述;下面是一个简短的总结。每一行的格式如下:
15662306a36Sopenharmony_ci
15762306a36Sopenharmony_ci::
15862306a36Sopenharmony_ci
15962306a36Sopenharmony_ci	tag: Full Name <email address>  optional-other-stuff
16062306a36Sopenharmony_ci
16162306a36Sopenharmony_ci常用的标签有:
16262306a36Sopenharmony_ci
16362306a36Sopenharmony_ci - Signed-off-by: 这是一个开发人员的证明,证明他或她有权提交补丁以包含到内核
16462306a36Sopenharmony_ci   中。这表明同意开发者来源认证协议,其全文见
16562306a36Sopenharmony_ci   :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
16662306a36Sopenharmony_ci   如果没有合适的签字,则不能合并到主线中。
16762306a36Sopenharmony_ci
16862306a36Sopenharmony_ci - Co-developed-by: 声明补丁是由多个开发人员共同创建的;当几个人在一个补丁上
16962306a36Sopenharmony_ci   工作时,它用于给出共同作者(除了 From: 所给出的作者之外)。由于
17062306a36Sopenharmony_ci   Co-developed-by: 表示作者身份,所以每个共同开发人,必须紧跟在相关合作作者
17162306a36Sopenharmony_ci   的Signed-off-by之后。具体内容和示例见以下文件
17262306a36Sopenharmony_ci   :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
17362306a36Sopenharmony_ci
17462306a36Sopenharmony_ci - Acked-by: 表示另一个开发人员(通常是相关代码的维护人员)同意补丁适合包含
17562306a36Sopenharmony_ci   在内核中。
17662306a36Sopenharmony_ci
17762306a36Sopenharmony_ci - Tested-by: 声明某人已经测试了补丁并确认它可以工作。
17862306a36Sopenharmony_ci
17962306a36Sopenharmony_ci - Reviewed-by: 表示某开发人员已经审查了补丁的正确性;有关详细信息,请参阅
18062306a36Sopenharmony_ci   :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
18162306a36Sopenharmony_ci
18262306a36Sopenharmony_ci - Reported-by: 指定报告此补丁修复的问题的用户;此标记用于表示感谢。
18362306a36Sopenharmony_ci
18462306a36Sopenharmony_ci - Cc:指定某人收到了补丁的副本,并有机会对此发表评论。
18562306a36Sopenharmony_ci
18662306a36Sopenharmony_ci在补丁中添加标签时要小心:只有Cc:才适合在没有指定人员明确许可的情况下添加。
18762306a36Sopenharmony_ci
18862306a36Sopenharmony_ci寄送补丁
18962306a36Sopenharmony_ci--------
19062306a36Sopenharmony_ci
19162306a36Sopenharmony_ci在寄送补丁之前,您还需要注意以下几点:
19262306a36Sopenharmony_ci
19362306a36Sopenharmony_ci - 您确定您的邮件发送程序不会损坏补丁吗?被邮件客户端更改空白或修饰了行的补丁
19462306a36Sopenharmony_ci   无法被另一端接受,并且通常不会进行任何详细检查。如果有任何疑问,先把补丁寄
19562306a36Sopenharmony_ci   给你自己,让你自己确定它是完好无损的。
19662306a36Sopenharmony_ci
19762306a36Sopenharmony_ci   :ref:`Documentation/translations/zh_CN/process/email-clients.rst <cn_email_clients>`
19862306a36Sopenharmony_ci   提供了一些有用的提示,可以让特定的邮件客户端正常发送补丁。
19962306a36Sopenharmony_ci
20062306a36Sopenharmony_ci - 你确定你的补丁没有荒唐的错误吗?您应该始终通过scripts/checkpatch.pl检查
20162306a36Sopenharmony_ci   补丁程序,并解决它提出的问题。请记住,checkpatch.pl,虽然体现了对内核补丁
20262306a36Sopenharmony_ci   应该是什么样的大量思考,但它并不比您聪明。如果修复checkpatch.pl给的问题会
20362306a36Sopenharmony_ci   使代码变得更糟,请不要这样做。
20462306a36Sopenharmony_ci
20562306a36Sopenharmony_ci补丁应始终以纯文本形式发送。请不要将它们作为附件发送;这使得审阅者在答复中更难
20662306a36Sopenharmony_ci引用补丁的部分。相反,只需将补丁直接放到您的消息中。
20762306a36Sopenharmony_ci
20862306a36Sopenharmony_ci寄出补丁时,重要的是将副本发送给任何可能感兴趣的人。与其他一些项目不同,内核
20962306a36Sopenharmony_ci鼓励人们甚至错误地发送过多的副本;不要假定相关人员会看到您在邮件列表中的发布。
21062306a36Sopenharmony_ci尤其是,副本应发送至:
21162306a36Sopenharmony_ci
21262306a36Sopenharmony_ci - 受影响子系统的维护人员。如前所述,维护人员文件是查找这些人员的首选地方。
21362306a36Sopenharmony_ci
21462306a36Sopenharmony_ci - 其他在同一领域工作的开发人员,尤其是那些现在可能在那里工作的开发人员。使用
21562306a36Sopenharmony_ci   git查看还有谁修改了您正在处理的文件,这很有帮助。
21662306a36Sopenharmony_ci
21762306a36Sopenharmony_ci - 如果您对某错误报告或功能请求做出响应,也可以抄送原始发送人。
21862306a36Sopenharmony_ci
21962306a36Sopenharmony_ci - 将副本发送到相关邮件列表,或者若无相关列表,则发送到linux-kernel列表。
22062306a36Sopenharmony_ci
22162306a36Sopenharmony_ci - 如果您正在修复一个缺陷,请考虑该修复是否应进入下一个稳定更新。如果是这样,
22262306a36Sopenharmony_ci   补丁副本也应发到stable@vger.kernel.org 。另外,在补丁本身的标签中添加一个
22362306a36Sopenharmony_ci   “Cc: stable@vger.kernel.org”;这将使稳定版团队在修复进入主线时收到通知。
22462306a36Sopenharmony_ci
22562306a36Sopenharmony_ci当为一个补丁选择接收者时,最好清楚你认为谁最终会接受这个补丁并将其合并。虽然
22662306a36Sopenharmony_ci可以将补丁直接发给Linus Torvalds并让他合并,但通常情况下不会这样做。Linus很
22762306a36Sopenharmony_ci忙,并且有子系统维护人员负责监视内核的特定部分。通常您会希望维护人员合并您的
22862306a36Sopenharmony_ci补丁。如果没有明显的维护人员,Andrew Morton通常是最后的补丁接收者。
22962306a36Sopenharmony_ci
23062306a36Sopenharmony_ci补丁需要好的主题行。补丁主题行的规范格式如下:
23162306a36Sopenharmony_ci
23262306a36Sopenharmony_ci::
23362306a36Sopenharmony_ci
23462306a36Sopenharmony_ci	[PATCH nn/mm] subsys: one-line description of the patch
23562306a36Sopenharmony_ci
23662306a36Sopenharmony_ci其中“nn”是补丁的序号,“mm”是系列中补丁的总数,“subsys”是受影响子系统的
23762306a36Sopenharmony_ci名称。当然,一个单独的补丁可以省略nn/mm23862306a36Sopenharmony_ci
23962306a36Sopenharmony_ci如果您有一系列重要的补丁,那么通常发送一个简介作为第〇部分。不过,这个约定
24062306a36Sopenharmony_ci并没有得到普遍遵循;如果您使用它,请记住简介中的信息不会进入内核变更日志。
24162306a36Sopenharmony_ci因此,请确保补丁本身具有完整的变更日志信息。
24262306a36Sopenharmony_ci
24362306a36Sopenharmony_ci一般来说,多部分补丁的第二部分和后续部分应作为对第一部分的回复发送,以便它们
24462306a36Sopenharmony_ci在接收端都连接在一起。像git和coilt这样的工具有命令,可以通过适当的线程发送
24562306a36Sopenharmony_ci一组补丁。但是,如果您有一长串补丁,并正使用git,请不要使用–-chain-reply-to
24662306a36Sopenharmony_ci选项,以避免创建过深的嵌套。
247