[PATCH 3/5] docs/zh_CN: update the translation of process/7.AdvancedTopics.rst

Patch content 1 changed file

Update to the commit 6e55b1cbf05d ("docs: try to encourage (netdev?)reviewers") scripts/checktransupdate.py reports: Documentation/translations/zh_CN/process/7.AdvancedTopics.rstcommit 6e55b1cbf05d ("docs: try to encourage (netdev?) reviewers")1 commits needs resolving in total Signed-off-by: Dongliang Mu <dzm91@hust.edu.cn>--- .../zh_CN/process/7.AdvancedTopics.rst             | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rstindex 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 等方面的内容，认为没有问题。”显然，以某种形式提供评审信息或回复+是必要的，否则维护者将完全无法知晓评审者是否已查看过补丁！++最后但同样重要的是，补丁评审可能会变成一个聚焦于指出问题的负面过程。请偶尔给予+称赞，尤其是对新手贡献者！-- 2.43.0