发现故事于近期 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/