diff options
Diffstat (limited to 'Documentation/translations/zh_CN/process/submitting-patches.rst')
-rw-r--r-- | Documentation/translations/zh_CN/process/submitting-patches.rst | 41 |
1 files changed, 9 insertions, 32 deletions
diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst index 437c23b367bb..a9570165582a 100644 --- a/Documentation/translations/zh_CN/process/submitting-patches.rst +++ b/Documentation/translations/zh_CN/process/submitting-patches.rst @@ -91,7 +91,7 @@ :ref:`cn_split_changes` 如果你用 ``git`` , ``git rebase -i`` 可以帮助你这一点。如果你不用 ``git``, -``quilt`` <http://savannah.nongnu.org/projects/quilt> 另外一个流行的选择。 +``quilt`` <https://savannah.nongnu.org/projects/quilt> 另外一个流行的选择。 .. _cn_describe_changes: @@ -127,13 +127,13 @@ URL来查找补丁描述并将其放入补丁中。也就是说,补丁(系列)及其描述应该是独立的。 这对维护人员和审查人员都有好处。一些评审者可能甚至没有收到补丁的早期版本。 -描述你在命令语气中的变化,例如“make xyzzy do frotz”而不是“[这个补丁]make -xyzzy do frotz”或“[我]changed xyzzy to do frotz”,就好像你在命令代码库改变 +描述你在命令语气中的变化,例如“make xyzzy do frotz”而不是“[This patch]make +xyzzy do frotz”或“[I]changed xyzzy to do frotz”,就好像你在命令代码库改变 它的行为一样。 如果修补程序修复了一个记录的bug条目,请按编号和URL引用该bug条目。如果补丁来 自邮件列表讨论,请给出邮件列表存档的URL;使用带有 ``Message-ID`` 的 -https://lkml.kernel.org/ 重定向,以确保链接不会过时。 +https://lore.kernel.org/ 重定向,以确保链接不会过时。 但是,在没有外部资源的情况下,尽量让你的解释可理解。除了提供邮件列表存档或 bug的URL之外,还要总结需要提交补丁的相关讨论要点。 @@ -254,29 +254,6 @@ Linus Torvalds 是决定改动能否进入 Linux 内核的最终裁决者。他 手册页补丁,或至少发送更改通知,以便一些信息进入手册页。还应将用户空间API 更改复制到 linux-api@vger.kernel.org。 -对于小的补丁,你也许会CC到搜集琐碎补丁的邮件列表(Trivial Patch Monkey) -trivial@kernel.org,那里专门收集琐碎的补丁。下面这样的补丁会被看作“琐碎的” -补丁: - - - 文档的拼写修正。 - - 修正会影响到 grep(1) 的拼写。 - - 警告信息修正(频繁的打印无用的警告是不好的。) - - 编译错误修正(代码逻辑的确是对的,只是编译有问题。) - - 运行时修正(只要真的修正了错误。) - - 移除使用了被废弃的函数/宏的代码(例如 check_region。) - - 联系方式和文档修正。 - - 用可移植的代码替换不可移植的代码(即使在体系结构相关的代码中,既然有 - - 人拷贝,只要它是琐碎的) - - 任何文件的作者/维护者对该文件的改动(例如 patch monkey 在重传模式下) - -(译注,关于“琐碎补丁”的一些说明:因为原文的这一部分写得比较简单,所以不得不 -违例写一下译注。"trivial"这个英文单词的本意是“琐碎的,不重要的。”但是在这里 -有稍微有一些变化,例如对一些明显的NULL指针的修正,属于运行时修正,会被归类 -到琐碎补丁里。虽然NULL指针的修正很重要,但是这样的修正往往很小而且很容易得到 -检验,所以也被归入琐碎补丁。琐碎补丁更精确的归类应该是 -“simple, localized & easy to verify”,也就是说简单的,局部的和易于检验的。 -trivial@kernel.org邮件列表的目的是针对这样的补丁,为提交者提供一个中心,来 -降低提交的门槛。) 6) 没有 MIME 编码,没有链接,没有压缩,没有附件,只有纯文本 ----------------------------------------------------------- @@ -599,7 +576,7 @@ e-mail 标题中的“一句话概述”扼要的描述 e-mail 中的补丁。 将补丁与以前的相关讨论关联起来,例如,将bug修复程序链接到电子邮件和bug报告。 但是,对于多补丁系列,最好避免在回复时使用链接到该系列的旧版本。这样, 补丁的多个版本就不会成为电子邮件客户端中无法管理的引用序列。如果链接有用, -可以使用 https://lkml.kernel.org/ 重定向器(例如,在封面电子邮件文本中) +可以使用 https://lore.kernel.org/ 重定向器(例如,在封面电子邮件文本中) 链接到补丁系列的早期版本。 16) 发送git pull请求 @@ -649,10 +626,10 @@ pull 请求还应该包含一条整体消息,说明请求中将包含什么, -------- Andrew Morton, "The perfect patch" (tpp). - <http://www.ozlabs.org/~akpm/stuff/tpp.txt> + <https://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". - <http://linux.yyz.us/patch-format.html> + <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html> Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/linux/maintainer.html> @@ -668,13 +645,13 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/linux/maintainer-06.html> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <https://lkml.org/lkml/2005/7/11/336> + <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net> Kernel Documentation/process/coding-style.rst: :ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>` Linus Torvalds's mail on the canonical patch format: - <http://lkml.org/lkml/2005/4/7/183> + <https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org> Andi Kleen, "On submitting kernel patches" Some strategies to get difficult or controversial changes in. |