linux kernel maintainer 很严格

文章目录

Krzysztof Wilczyński第一位 Niklas Cassel第二位 Ilpo Järvinen第三位 作者我第四位 公司同事

这里主要介绍平日里在社区的亲身经历，以及从订阅邮件中看到的趣事。

Krzysztof Wilczyński

对于这位Maintainer，我也是深受 “其害”，不光是我，我们公司的同事，社区中有100多个，500多个patch经历的人都被这位大佬说过。

以下就一一讲讲其中的过程。

第一位 Niklas Cassel

Niklas 在linux kernel中提交成功的patch数量——150个。
这位并不是Maintainer，是一个普通的的贡献者，最开始看他在PCIe domain很活跃，我的第一个patch就是fix他之前提交代码的一个bug。

后来有的patch想让他给出一些审核意见，他回复我并不是Maintainer。

他与 Krzysztof 有一点点摩擦是从我的一个patch开始。起因是我在发送下一个版本的时候，主要更改是增加Maintainer的审核标签：Reviewed-by，

patch的subject版本并没有加1，而是 RESEND + 老版本号。Krzysztof觉得不能 RESEND + 老版本号，Niklas 觉得没有问题，因为patch本身没有改动，只是添加审核标签，主要是为了防止丢弃掉审核者的标签，也会浪费别人付出的时间审核过了。

重点来了：【 这里会贴上原文，以及译文：有道翻译 😃 】

Niklas 在 邮件中提醒 Krzysztof 邮箱名称有错误码。

你好，克日什托夫，

供您参考：我的收件箱里您的名字显示有误。
发件人：克日什托夫·维尔奇斯基 <您的电子邮箱地址>
或许是因为：
内容类型：纯文本；字符集=美国标准信息交换码
而不是 UTF-8 吗？

查看了差异，我觉得这些改动没问题，但我强烈认为，如果实际代码与提交的内容有修改（而非只是修正提交信息中的某些小语法错误），那么（不成文的？）规定是提交者应当添加一个：
[人员：描述与原始提交内容的不同之处]
在原始提交的“Signed-off-by”行之后添加一行，例如，如果更改的行中存在错误，那么原始作者就不会因一些并非他所写的代码而受到不公正的指责。
仅修改提交日志时，不可能引入功能变更，但只要代码/差异被修改，就有可能（有意或无意地）引入功能变更，所以这两种情况之间存在很大差异（依我拙见）。

抱歉，我确实忘了加上这个。你提醒得真好。
话虽如此，只需一条简单的提示或提醒信息就足够了。
没必要摆出一副高人一等的腔调，也没必要说教之类的。
你这样已经有一阵子了，如果你继续这样下去，我别无选择，只能开始忽略你的提
交内容，我没有时间去应付这种消极对抗的态度。

我已将回复内容反复阅读了好几遍，但说实话，我实在不明白这究竟是怎么回事。
我只是想说，如果在应用时实际的代码发生了更改，那么我认为有必要采取以下两
种做法之一：
1）在相应线程中（比如在“已应用”消息中）添加相关内容，
2）在“标准操作流程”之后添加一个 [用户：] 的标注。
至于仅仅修改提交日志这一方面，我个人认为 1）和/或 2）这两点的重要性要低
得多。
我并非想要进行说教，我只是想阐明自己观点的逻辑依据。
这让我感到很惊讶，我们最近仅有的另一次交流是关于“重新发送”标签的，当时我
也表达了我个人的看法。
但在我看来，那也是一次合理的讨论。
在进行重新提交操作时（只要代码和提交日志未发生变化），不允许添加诸如
“Reviewed-by”和“Tested-by”这样的标签，这在我看来似乎有些得不偿失，因
为测试人员/审核人员所花费的时间就白白浪费了。

第二位 Ilpo Järvinen

Ilpo 在linux kernel中提交成功的patch数量——575个。

此patch就是将打印信息从两行变为一行。

我不知道是否还存在“琐碎补丁维护者”这样的东西，所以我将拉这个。
我猜，这一定让你有些困扰。也就是说，我…你的专业知识和时间本可以用在不同的地方。:）

然后直接将这个patch接受了，并放入到临时分支中。

做这样的补丁并不需要很长时间，我也不会刻意去寻找这样的东西，也不会专注于它们。只是当我以不同的方式使用我的专业知识时，我也遇到了这些简单的问题。你可以查看我最近发现的跟踪记录，例如真正的并发问题，所以我希望你能在这里和那里给一些琐碎的补丁；-)。

我们喜欢你的作品！对细节无与伦比的关注，尤其是。：）
关于琐碎补丁的话题…在社区中有一个关于琐碎补丁的大争论，per：
https://lore.kernel.org/all/YIGXzB0CyRtGfqfE@zeniv-ca.linux.org.uk/t/
有很多观点…最终，大多数情况下，像往常一样，事情取决于维护人员。
再次感谢您所做的一切！感谢!

第三位 作者我

我需要花些时间去调查一下这个问题，所以我选择去做别的事情了。最近在争论时我总是很不耐烦，会说“我在别处看到过这个”。我在别处发现了漏洞，所以我觉得我可以引入这个内容了。

真的是有两个人对这些微小的改动进行了审查吗？真的吗？

此外，他们的审查实际上检查了什么呢？这显然是错误的——没有遵循 DTS 编码风格，那么这样的审查意味着什么？它到底意味着什么？

总结：没事别去加DTS，DT binding文档，如果你不信邪，那你就会被吊打一顿。

第四位 公司同事

这是无用的重复信息。两次。
你可以很容易地自己发现问题，而不是一直为这些琐碎的事情去烦审稿人。
NAK，请记住不要浪费评论者的时间。

> 你看到两次，每一个引脚控制器一次。顺便说一句，正如你之前建议的，我们将在错误消息中打印ret的值。
> 如果我遗漏了什么信息，请提醒我。谢谢

你还是无视我的第二条评论。

是的，我理解这种想法。

非探针式引脚控制驱动程序的典型症状是：例如，系统无法挂载根文件系统，因为连接到 eMMC 的某些引脚未正确进行多路复用。

人们迟早都会发现这个问题的，只是打印出来之后会让问题显现得更快一些而已。而且这种错误相当常见（至少对我来说是这样，但我并非最出色的开发人员……）

最后奉劝大家，能不提patch就不提patch，除非你能扛喷。

欢迎关注作者微信公众号：不定期发布PCIe相关的知识点，linux kernel 社区的一些有趣的动态。