From: Dongliang Mu Date: Tue, 10 Jun 2025 12:30:28 +0000 (+0800) Subject: docs/zh_CN: update the translation of process/7.AdvancedTopics.rst X-Git-Tag: io_uring-6.17-20250815~111^2~18^2~10 X-Git-Url: https://git.kernel.dk/?a=commitdiff_plain;h=42f3bf6916a04a7a65495640c37c9214abb79abd;p=linux-block.git docs/zh_CN: update the translation of process/7.AdvancedTopics.rst Update to the commit 6e55b1cbf05d ("docs: try to encourage (netdev?) reviewers") scripts/checktransupdate.py reports: Documentation/translations/zh_CN/process/7.AdvancedTopics.rst commit 6e55b1cbf05d ("docs: try to encourage (netdev?) reviewers") 1 commits needs resolving in total Signed-off-by: Dongliang Mu Signed-off-by: Alex Shi --- diff --git a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst index 57beca02181c..92cc06dd5f4e 100644 --- a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst +++ b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst @@ -113,6 +113,8 @@ Git提供了一些强大的工具，可以让您重写开发历史。一个不 更改。在这方面 git request-pull 命令非常有用；它将按照其他开发人员所期望的 格式化请求，并检查以确保您已记得将这些更改推送到公共服务器。 +.. _cn_development_advancedtopics_reviews: + 审阅补丁 -------- @@ -126,8 +128,20 @@ Git提供了一些强大的工具，可以让您重写开发历史。一个不 的建议是：把审阅评论当成问题而不是批评。询问“在这条路径中如何释放锁？” 总是比说“这里的锁是错误的”更好。 +当出现分歧时，另一个有用的技巧是邀请他人参与讨论。如果交流数次后讨论陷入僵局， +可征求其他评审者或维护者的意见。通常，与某一评审者意见一致的人往往会保持沉默， +除非被主动询问。众人意见会产生成倍的影响力。 + 不同的开发人员将从不同的角度审查代码。部分人会主要关注代码风格以及代码行是 否有尾随空格。其他人会主要关注补丁作为一个整体实现的变更是否对内核有好处。 同时也有人会检查是否存在锁问题、堆栈使用过度、可能的安全问题、在其他地方 发现的代码重复、足够的文档、对性能的不利影响、用户空间ABI更改等。所有类型 的检查，只要它们能引导更好的代码进入内核，都是受欢迎和值得的。 + +使用诸如 ``Reviewed-by`` 这类特定标签并无严格要求。事实上，即便提供了标签，也 +更鼓励用平实的英文撰写评审意见，因为这样的内容信息量更大，例如，“我查看了此次 +提交中 A、B、C 等方面的内容，认为没有问题。”显然，以某种形式提供评审信息或回复 +是必要的，否则维护者将完全无法知晓评审者是否已查看过补丁！ + +最后但同样重要的是，补丁评审可能会变成一个聚焦于指出问题的负面过程。请偶尔给予 +称赞，尤其是对新手贡献者！