发现故事于近期 LinuxWeeklyNews 之 Quotes of the week (语录) 环节:
http://lwn.net/Articles/359270/
The fact is, maintainership does _not_ mean ownership. It means that
you should be _responsible_ for the code, and you get credit for it,
but if problems happen you do NOT "own" it. Not at all.
If you don't understand that, you shouldn't be a maintainer.
-- Linus Torvalds
事实是,维护不是意味着你拥有这部分代码;而是你要对它负责任,你从中获得荣誉和别人的称赞;而当问题发生时,你并不承担错误;完全不是;
可以进一步这封邮件的全文:
http://lwn.net/Articles/360156/
这封出自 Linus 的邮件第一句话就是 "You're full of sh*t." (你就是一坨屎) ...
如果你再有时间和兴趣,还可以进一步阅读讨论线索之全文,以了解整个事件之来龙去脉:
http://thread.gmane.org/gmane.linux.kernel/908831/focus=41872
邮件线索原始标题: "请考虑重置 commit 7d930bc" (即反转 commit 7d930bc 的所有修改)
1) Dmitry Torokhov 报告 2.6.32-rc5 中 cfg80211 (也就是 wireless 部分) 出现 Kernel Oops, 经过一番艰苦 git bisect 之后,发现引起问题的原因在于 commit 7d930bc, 重置这号 commit 之后可以解决;可见这确实是一个邪恶的 commit, 而且 git show 显示它引入于 2.6.32-rc5 之后;
2) David Miller (net-2.6 总管) 说在我的 net-2.6.git 树已修正了,稍晚会推送给 Linus;
3) 这时 Marcel Holtmann 忽然说了句 这个事件是这样解决了,但类似事件我们是不是可以改进下工作流,更多考虑下 最直接那个 MAINTAINER 的看法? (Wireless 的 cfg80211 和 nl80211 接口部分维护人是 Johannes Berg) 让他能有个说句话的机会,而不是直接跳过去了?
4) Johannes Berg 说话了,"唉,类似问题困扰已久" 指的是工作流上,当问题发生时,人们都直接找 Linus 或其它几位顶级 MAINTAINER 要求重置了那个出问题的 commit, 甚至也不通知一下 那个 commit 的原始作者和我们这些底层的 MAINTAINER, 导致我们反而后知后觉,后面 merging 过程中麻烦多多;所以能不能先发给我们,以标题类似于 "发现问题于 某 commit, 我们看怎么解决?"
5) Dmitry Torokhov: 我不明白问题出在哪里,我都已经抄送给 wireless 邮件列表了,我觉得在 -rc5 之后我们要迅速地解决问题
6) Johannes Berg: 我不反对要迅速解决问题,你当然可以直接发给Linus要求直接revert,我只是说能不能先发给MAINTAINER(也就是我了),我们有了更好的办法再汇报给Linus不晚哪,因为有时候 仅仅一个 revert 是不够的,因为原来那个 commit 肯定也是解决了某事情,如果我们直接 revert 可能会导致更糟糕的事情;这种工作流显得更为友好;而不是只被列在Cc里面,好像MAINTAINER的意见只是第二位的;
7) Dmitry Torokhov: 是说 To: 和Cc: 差别待遇吗?好了好了,下次我把你们全列在 To: 里面好吧
8) Marcel Holtmann: 近期我也发现有这种趋势:人们就不管三七二十一,上来就要示 revert, 然后才考虑解决真正的解决问题;
9) Linus 发火了: "你就是一坨屎" BUG 终究是BUG 就要被 revert 掉;那些在 merge window (rc2) 之后还引入 BUG 的人们应该被钉在耻辱柱上;一个 commit 引入的问题比它修正的要多,你说我们是不是就该要 revert 它?
10) Andrew Morton: subsystem maintainers 通常都很不靠谱
11) David Miller: To Andrew: 这很 平常 (common), 但不是普遍的 (universal)
12) Andrew Morton: David, 顺便把这几个 patch 从 -mm 树给接过去?
13) David Miller: 没问题,已应用至 net-2.6 树;其中有个 isdn-eicon-return-on-error.patch 又在用自动格式化工具玩大便 (holy crap someone run that driver through some auto-formatting tool!)
14) Linus Torvalds: 坦率地说,我还是对这个bug是非常的不满意:1) 它是 -rc5 之后引入的 2) 它被多人 bisect 出来,这浪费了多少人的时间? 3) 此 commit 的原始作者(Johannes Berg) 在被告知了 具体哪一个 commit 导致的问题却还想从报告者那里等待更多的信息(你都已经被通知这号commit有问题了,你就不能自己搞定吗?);
15) Marcel Holtmann: 当然是需要修正,但盲目地 revert 可能导致其它副作用; And to be honest, Johannes Berg 在解决 wireless 问题上还是很积极的;
16) Linus Torvalds: 每个人都知道出一问题要修正它;但真正的问题是"我们要最快地修正它" revert 就是最快的办法 我等不及 subsystem maintainer 来修正它;(To Marcel)你别光说讨好的漂亮话了;你错了,你应该感谢 Dmitry ,请求原谅浪费了他的时间;
17) Marcel Holtmann: 其实四天前我的邮箱就有了 Johannes 发过来的 解决办法的 patch 了,你的意思是要我当时就 越过 MAINTAINER (Johannes and David Miller) 直接把它发送给你?
18) Linus Torvalds: 你要我们的用户再多等一天还是再多等五天? 在 -rc5 之后出现的问题我们要在最快的时间把它修正,即使不是最优的结果,但我们的测试用户有多少时间给我们浪费的? 我们要做的就是 "Deal with it", And yes, 有时候 "Dealing with it" 就意味着必要时绕过维护者。 最差的情况下 我们有这样一个严格的管道在必要时 让用户不必在 MAINTAINER 路上等待太多时间
19) Marcel Holtmann: 我也同意。但是公平说,这个 bug 并不是影响着所有人 ...
20) Linus Torvalds: 不是的,你又错了。我是被动卷入这个线索的,其实看一眼那个 commit 就知道那个 memcpy 就有 NULL pointer dereference 问题。有人撞上了这个 problem 这就够了
21) Ingo Molnar 插入: 列举 Johannes 前两天的一封回复邮件,以说明其(Johannes)回复是 无用的, 不负责任的 (Unhelpful, defensive, in denial.) 你的 "hey, nothing happened, we fixed it after all" 表示你对此的无知,此类可避免的事故在将来还会重演
22) Marcel Holtmann: 谁这么说话了?那不是我说的好不好?
23) Ingo Molnar: 没在说你。是说上面写那个邮件的那个人,上面已 quote (就是 Johannes 写的) 部分
24) ... 有时候BUG比较复杂,1天还搞不定;这就证明了你是不够 responsive; 接着讨论要做到什么样才能叫做 responsive, 多少时间响应? ...
25) Linus Torvalds: 拜托,两天看起来是不多,但我们的 merge window 关闭已有5个星期了,我们马上就要发布 (2.6.32) 了
Linus 对 Kernel 还是相当严格,顺便也提到 Mailing list 这个 "Immediate but asynchronous" 交流方式的优点,
顺便 David Miller 提到有人还在玩 auto-formatting tool 提交补丁,这种在刚开始入门时尚可,入门久了,再玩就没什么意思了,还会引起人家反感,请看这里的二楼评论;
http://roclinux.cn/?p=1440
BTW, 近期发现 有人 做的 KernelPodcast 不错,以语音的方式为大家播报最近 Kernel 进展和人物事件, 可以同时 作为内核 学习 和 英语 学习材料:只是希望可以持久下去, 这样的工作除了 LWN 可以作为全职以外,一般人恐怕很难持续下去:
http://www.kernelpodcast.org/feed/