如何为社区提交patch
为Linux社区提交patch
描述patch更改
提出问题：首先阐述你的patch要解决的问题，无论是一行的代码bug修复或者增加5000+行的新特性。
注意查看优化和平衡，最优往往都是有代价的。
描述技术细节：一旦问题建立，那么就需要详细描述你的技术细节。
每一个patch仅解决一个问题：当你的patch太长，那么你需要将其分割。
包含完整的patch描述：提交patch时，需要包含完整的正当性描述，不要仅仅说这是第几版patch。
不要仅仅包含一个commit的SHA-1 ID：如果想要引用一个具体的commit，不要仅仅提供一个SHA-1 ID，也要包含一行commit的总结，来方便reviewer更容易理解。至少包含前12个SHA-1 ID字符，内核中的object相当的多，字符较少时碰撞是大概率的，即使现在没有，也不能保证五年以后~~~
当你的patch修复了一个指定commit的bug：使用Fixes:tag加12个字符的SHA-1 ID，还有一行的总结。
如何分割你的patch
当你的patch包含一个bug修复和一个性能增强：将他们分为两个或更多patch。
如果你新增了一个API，并在另一个文件使用了这个API：将他们分为两个。
如果你对多个文件做了同一个更改：将这些更改作为一个patch即可，因为这是同个逻辑的修改。
每一个补丁都应该便于理解：每一个补丁都应该是合理的，并且有他们自己的merits。
如果一个patch依赖另一个patch：简单的标记“this patch depends on patch X”即可。
分割patch时，特别注意内核能否构建和运行：patch序列中的每一个哦。
当时实在无法压缩你的patch set：那么，你可以每次发送15个左右，然后等待review和integration。
代码风格
不检查代码风格是在浪费reviewer的时间：当然也会导致你的patch被拒绝。
一种例外：当你仅仅是移动一段代码从一个文件到另一个地方，那么你的patch应该保持干净，这个patch应该仅有移动的动作。
代码风格检查脚本：scripts/checkpatch.pl
选择patch的接受人
发现MAINTAINERS的脚本：scripts/get_maintainer.pl
实在找不到MAINTAINERS：找 Andrew Morton (akpm@linux-foundation.org)
选择一个邮件列表：linux-kernel@vger.kernel.org 是最后的手段（这个内容太多了），通常你应该在MAINTAINERS文件中找特定子系统的邮件列表，你的补丁可以获得更多关注，但是不要向无关的列表发送垃圾邮件。
不要一次发送超过15个邮件！！！！
安全相关的patch：如果你修复了一个安全相关的bug，发送邮件到security@kernel.org，修复一个发行版的严重bug时，需要同时抄送到stable maintainers。
1 | |
添加Sign-off
如果你的修改涉及内核用户态：发送一个man-page patch到MAN-PAGES的MAINTAINERS，或者至少发送一个更改通知，用户空间的API修改也应该备份到linux-api@vger.kernel.org。
一些琐碎的patch：也许你可以抄送到Trivial Patch Monkeytrivial@kernel.org。
邮件大小
当你的邮件大小超过300k：不要将过大的邮件发送到邮件列表和maintainers，超过300k的邮件更好的方法是将你的patch放在服务器上，并且提供一个URL指向你的patch。特别注意：如果你的patch超过300k，几乎可以确定它需要分解。
响应审查评论
忽略评审人是一个被评审人忽略的好办法：不会带来代码更改的评论或问题几乎肯定会带来评论或者日志的更改，以便于下一个评审人更好的理解发生了什么。
保持耐心
评审人很忙：在确保发送到执行位置后，耐心等待至少一周。
邮件请加[PATCH]前缀
在补丁邮件前加[PATCH]前缀：以便于linus和其他内核开发者注意到。
开发者的个人标识
在你的补丁中，添加sign-off：作为你的补丁标识（请使用真实姓名）
1 | |
当你作为一个maintainer：你有时会需要修改补丁，然后才能将其合入，你可以在提交者的sign-off之下和你的sign-off中间增加一行，指明你修改的特性。
1 | |
特殊的向后兼容：在commit message顶部，Date的下面，增加一个标识
1 | |
或者，一旦补丁向后移植，会出现问题时
1 | |
一些有用的标识
Signed-off-by：谁完成了整个补丁。
Acked-by：通常被用来既不贡献也不转发补丁时使用。不像Signed-off-by那样正式，acker至少审查了该patch并表示接受。并且，该标识并不一定表示对整个补丁的确认，例如，如果一个补丁影响多个子系统，那么来自某个子系统maintainer的ack表示仅对该子系统的影响。
可以通过Cc添加抄送
Co-Developed-by：共同开发者，当多人处理单个补丁时，这很有用，注意，此人还要再补丁中具有Signed-off-by
Reported-by：发现bug的人。
Tested-by：该补丁已经由指定的人员成功测试
Reviewed-by：指明该补丁已经被review过并且被接受。
Suggested-by：该补丁的想法是由指定的人建议的
Fixes：指明该补丁修复了一个bug在前面的commit中
patch的标准格式
from：指定补丁的作者
补丁正文：75列换行，将被永久复制到变更日志中以描述此补丁
一个空行：
Signed-off-by：一行，也会被加入到变更日志中
—：标识行，仅包含—，标志变更日志结束，— 标记后面的附加注释的一个很好的用途是用于 diffstat，显示哪些文件已更改，以及每个文件插入和删除的行数。 diffstat 对于较大的补丁特别有用。 其他仅与当前或维护者相关、不适合永久变更日志的评论也应该放在这里。 此类注释的一个很好的例子可能是补丁更改日志，它描述了补丁的 v1 和 v2 版本之间发生的更改。
任何不适合变更日志的附加评论
事实上的补丁：diff的输出
主题行格式：使得按主题字母顺序排序变得容易
标题应声明子系统：电子邮件主题中的子系统应标识正在修补内核的哪个区域或子系统。
标题摘要：简明地描述该邮件包含的补丁，你的标题摘要将成为你的补丁的唯一标识符（可以通过gitk或者git log –oneline来查看）。标题摘要不应该是文件名，不要使用相似的摘要在整个补丁集中。
基于以上理由，标题摘要必须满足不超过70-75个字符，同时既能描述补丁的change，也能说明补丁的必要性。
1 | |
摘要短语可以使用方括号中的标签作为前缀：标签不视为摘要的一部分，但描述了应该如何处理补丁，如多个版本v1,v2,v3，或者RFC（request for comments）请求评论，多个补丁需要补丁序列，如1/4, 2/4, 3/4, 4/4等
1 | |
1 | |
from必须是第一行：
1 | |
正文将永远进入到变更日志：解释正文将致力于永久源代码变更日志，因此对于那些早已忘记了可能导致此补丁的讨论的直接细节的有能力的读者来说应该是有意义的。 包含补丁所解决的故障症状（内核日志消息、oops 消息等）对于可能搜索提交日志以查找适用补丁的人来说特别有用。 如果补丁修复了编译失败，则可能不需要包含所有编译失败； 足以让搜索该补丁的人能够找到它。 正如摘要短语一样，简洁和描述性都很重要。
拉取请求
pull：如果你有一系列的patch，更方便的方法应该是由maintainer去pull你的代码到他的子系统仓库，然而，从邮件列表中pull需要更多的信任度，比起从开发人员那里来说。
拉取请求的主题行中，应该包含[GIT]或者[PULL]，请求本身应该包含仓库名和分支
1 | |
拉取请求还应该包含一条综述，说明请求中包含哪些内容，可以使用git request-pull