曾几何时，Linux 之父 Linus Torvalds 面对看不惯的事情时，都会毫不顾忌地”开炮“，譬如之前怒删工程师提交的补丁，还附上了一句“太蠢了”；而后炮轰”英特尔在扼杀整个 ECC 行业“；斥责工程师，称“你的代码就是垃圾！”......
不过，近几年通过不断地自我反省，他的脾气收敛了许多。现在几乎不怎么怼人的他，除非遇到一些实在看不下去的事情，还是想说上几句。就在最近，Linus Torvalds 在官宣 Linux 6.12-rc2 内核时，在邮件列表中花了一半的篇幅来提醒内核开发者们，让他们好好注意自己提交消息时候的用语，尤其是语法问题。
提交请求时，别用被动语态！
这里的语法问题不是指编码语法，而是指内核维护者提交消息时候写的英语用语语法。
Linus 透露自己过去在处理消息时的常规做法，会尽量让合并提交信息显得“有条理”一些，所以他经常会编辑拉取请求的语言，使其符合更标准的格式和表达方式。
他表示，“这不是什么大事，通常只是处理一下空格符号，这样我们就不会有十五种不同的缩进和项目符号语法。我一般是在阅读文本时顺便做的，所以也不会额外增加工作量。”
话锋一转，Linus 开始吐槽道：
但真正增加我工作量的，是当有些维护者使用被动语态时，我会试图主动重写解释（或者坦白说，有时我懒得去让所有信息听起来一样）。
所以我想请维护者尽量使用主动语态，最好是命令式的表达。
换句话说：我希望大家避免写出这样的描述：“在这个拉取请求中，Xyzzy 驱动程序的错误处理被修复以避免空指针引用”。
相反，可以写成“这个修复了空指针引用问题…” 或者如果你只是列出项目符号，请直接写成“修复了空指针引用问题…”。
我知道这不是什么大事，但上周我刚好重写了几个这样的例子，我认为简单、直截了当的语言更好。“修复 X”的命令式版本是最简洁明了的表达。
事实上，Linus 说的话不无道理。不少网友赞同道：
使用主动语态的重要性怎么强调都不为过。
被动语态经常出现在科学论文和技术写作中，但它可能令人困惑和恼火。它会导致表达不清，不仅引发对责任或行为主体的混淆，还经常掩盖了关键信息，比如谁应该做什么以及何时去做。因此，它非常适合某些供应商手册。
这里没有什么争议，这是非常标准的，我工作/维护的所有操作系统项目（以及我的日常工作）都使用命令式语言来发送 git 提交消息。
话虽有理，但是要放在过往 Linus 身上，内核贡献者免不了要遭一顿臭骂。所以，这次众人在看到 Linus 的邮件内容时，还是忍不住感叹道——Linus 的脾气真的温和了不少。
脾气变好的 Linus
之所以这么说，一方面是因为 Linus 这次在邮件列表中写的第一个词就是稍带些语气词的「Hmm」（嗯），顺便还跟大家分享了自己的一些发现。其表示：
Hmm，我通常的印象是，rc2（第二个候选版本）往往会是较小的一个版本，因为在合并窗口之后，大家都会稍作喘息，或者因为需要一些时间才能开始发现问题。
但至少这次发布并没有遵循这种模式。我还回顾了一下早期的 6.x 版本，做了一些统计，快速查看后发现这种情况实际上只有一半的概率成立。确实有些 rc2 版本相对较小，但并不是所有都是。我想我之前应该先跑一下这些数据。
总之，这次的 rc2 并不算小。不过看历史趋势，较大的 rc2 其实并不罕见，而且这里面也没有什么特别奇怪的东西。是的，差异统计（diffstat）可能看起来有点不寻常，因为我们进行了全局头文件重命名（从 asm/unaligned.h 到 linux/unaligned.h），还有几个回滚操作在统计中显得比较突出，但其他部分都很小巧。事实上，差异统计中另一个明显的高峰只是因为一些 folio 文档的更新，并不是代码更改。
大约占四分之一的差异是文件系统的变化，这次比平常稍大一些（如果不是其中一个回滚操作的话，实际上会比驱动程序的变化还要大），但这可能只是个随机的时间差。我预计下周会收到更多驱动更新。
另一方面，现在的他和过去形成了鲜明对比。还记得 2016 年，Red Hat 的一位工程师 Mauro Carvalho Chehab 把内核中的一个错误归咎于跨平台的音频服务器 Pulseaudio 和其他第三方应用的问题时，Linus 毫不留情地怒斥道：“Mauro，SHUT THE F**K UP！”
“这是个内核错误。担任维护者多久了？而且你还没学到内核维护的第一条规则吗？…修复你的内核编程方法。”
或许感觉骂得不够，他在邮件中继续补充说，“Mauro，闭嘴。我再也不想听到这种明显的垃圾和白痴的话。我是认真的。”
正因此，虽然现在看起来 Linus 对一些细节内容比较挑剔，但这实际上是他非常温和的评论了。
参考：