内核开发社区已经发展出一套用于发布补丁的约定和过程；遵循这些约定和过程将使
参与其中的每个人的生活更加轻松。本文件将试图合理详细地涵盖这些期望；更多信息
也可在以下文件中找到
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`,
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`,
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
和 :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.
其传递给diff。
上面提到的标签用于描述各种开发人员如何与这个补丁的开发相关联。
-:ref:`documentation/process/submitting-patches.rst <submittingpatches>`
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
文档中对它们进行了详细描述；下面是一个简短的总结。每一行的格式如下：
::
常用的标签有：
- Signed-off-by: 这是一个开发人员的证明，他或她有权提交补丁以包含到内核中。
- 这是开发来源认证协议，其全文可在:ref:`documentation/process/submitting-patches.rst <submittingpatches>`
+ 这是开发来源认证协议，其全文可在
+ :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
中找到，如果没有适当的签字，则不能合并到主线中。
- Co-developed-by: 声明补丁也是由另一个开发人员和原始作者一起创建的。当多
- Tested-by: 声明指定的人已经测试了补丁并发现它可以工作。
- Reviewed-by: 指定的开发人员已经审查了补丁的正确性；有关详细信息，请参阅
- :ref:`documentation/process/submitting-patches.rst <submittingpatches>`
+ :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
- Reported-by: 指定报告此补丁修复的问题的用户；此标记用于提供感谢。
- 将副本发送到相关邮件列表，或者，如果没有其他应用，则发送到Linux内核列表。
- 如果您正在修复一个bug，请考虑该修复是否应进入下一个稳定更新。如果是这样，
- stable@vger.kernel.org应该得到补丁的副本。另外，在补丁本身的标签中添加
+ stable@vger.kernel.org 应该得到补丁的副本。另外，在补丁本身的标签中添加
一个“cc:stable@vger.kernel.org”；这将使稳定团队在修复进入主线时收到通知。
当为一个补丁选择接收者时，最好知道你认为谁最终会接受这个补丁并将其合并。虽然
关于Linux内核开发和相关主题的信息来源很多。首先是在内核源代码分发中找到的
文档目录。顶级 :ref:`Documentation/translations/zh_CN/process/howto.rst <cn_process_howto>`
文件是一个重要的起点
-:ref:`process/submitting-patches.rst <submittingpatches>`
-和:ref:`process/submitting-drivers.rst <submittingdrivers>`
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
+和 :ref:`process/submitting-drivers.rst <submittingdrivers>`
也是所有内核开发人员都应该阅读的内容。许多内部内核API都是使用kerneldoc机制
记录的；“make htmldocs”或“make pdfdocs”可用于以HTML或PDF格式生成这些文档（
尽管某些发行版提供的tex版本会遇到内部限制，无法正确处理文档）。
-不同的网站在各个细节层次上讨论内核开发。您的作者想谦虚地建议用http://lwn.net/
+不同的网站在各个细节层次上讨论内核开发。您的作者想谦虚地建议用 http://lwn.net/
作为来源；有关许多特定内核主题的信息可以通过以下网址的lwn内核索引找到：
http://lwn.net/kernel/index/
范。大多数维护者只会接收符合规定的补丁，很多人也只会帮忙检查符合风格
的代码。
- :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+ :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
这两份文档明确描述如何创建和发送补丁，其中包括（但不仅限于)：
这几行。将你的评论加在被引用的段落之间而不要放在邮件的顶部。
如果你在邮件中附带补丁，请确认它们是可以直接阅读的纯文本（如
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
文档中所述）。内核开发者们不希望遇到附件或者被压缩了的补丁。只有这样才能
保证他们可以直接评论你的每行代码。请确保你使用的邮件发送程序不会修改空格
和制表符。一个防范性的测试方法是先将邮件发送给自己，然后自己尝试是否可以
- 没有“理论上的竞争条件”，除非能给出竞争条件如何被利用的解释。
- 不能存在任何的“琐碎的”修正（拼写修正，去掉多余空格之类的）。
- 必须被相关子系统的维护者接受。
- - 必须遵循Documentation/process/submitting-patches.rst里的规则。
+ - 必须遵循Documentation/translations/zh_CN/process/submitting-patches.rst里的规则。
向稳定版代码树提交补丁的过程：
------------------------------
的事情。
这些都是在
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
和其他有关提交Linux内核补丁的文档中提供的。
1) 如果使用工具，则包括定义/声明该工具的文件。不要依赖于其他头文件拉入您使用
兴趣的是显卡驱动程序，你也许应该访问 XFree86 项目(http://www.xfree86.org/)
和／或 X.org 项目 (http://x.org)。
-另请参阅 Documentation/process/submitting-patches.rst 文档。
+另请参阅 Documentation/Documentation/translations/zh_CN/process/submitting-patches.rst 文档。
分配设备号
projects / openwrt / staging / blogic.git / commitdiff