Linus Torvalds on the kernel development community
By Jonathan Corbet
Maintainers Summit
2019年9月12日在葡萄牙里斯本举行的Linux Kernel Maintainers Summit刚刚落幕。参与者都是基于邀请制请来的31位内核开发者，大家畅谈了对于kernel开发流程的意见。既然谈到开发流程，肯定就无法避免maintainer层级最顶端这位人士的看法，因此会中有一个专门的“is Linus happy?” session，现场看下来，整体工作流程还是比较让人满意的，不过当然也有改进空间。
Torvalds起初没有正面回答这个问题，他认为大家应该问的是除他之外的所有人是否对他的工作满意。不过后来他倒是提及了一点让他非常烦恼的做法：有些开发者总是不知道在推到mainline之前先提交到linux-next。特别是在5.3 merge window中他对一个子系统的tree并不满意，其他子系统tree过去也出过问题，不过都有了很多改善，但是他比较头疼的是每一轮都有这种问题。总体来说，10%的patch没有先在linux-next里面出现。
Dan Willianms问道有没有一个规则说一定要在合入upstream的至少24小时之前就必须提交到linux-next。Torvads回答说在merge window早期阶段他其实根本不检查每个patch是否在linux-next，只要他能尽早拿到pull request他就很开心了，没有其他要求。不过merge window靠近尾声的时候，他就会开始检查这一点，假如某个patch不再linux-next（在merge window早期）的话，pull request可能就不会被合入。
Sasha Levin问道，在-rc1之后，是否还会进行这个检查？Torvalds的回答是“通常不会”。在merge window结束之后合入mainline的代码主要是一些重要的bug fix，而linux-next对这种问题帮助不大。在Torvalds看来，bug fix没在linux-next上先出现，这并没什么问题。Levin指出bug fix也经常会导致问题，所以放到linux-next里面至少能让CI（持续集成）系统能有机会提前发现这个问题。linux-next的maintainer Stephen Rothwell指出他有一个单独的fixes tree，可以独立于linux-next来进行测试，甚至可以更加频繁。
Torvalds说，很多开发者没有意识到linux-next的操作是需要人主动来提交的。这里并没有说推入一个改动就会触发什么自动测试。linux-next的patch可能需要几天时间才会经过验证，相应的，mainline的patch就会马上被验证。这里其实还有个规则，就是mainline上的patch要在合入至少一周之后，才会被选取合入stable release的kernel上。通常bug fix patch会再经过一轮-rc release，有可能还不到一周的时候就被合入stable kernel。
Ted Ts'o介绍说他以前做法是把改动推到他自己的ext4 tree，然后0day tester会在几小时内拿到测试结果。不过近来已经不是这么弄的了。他很希望能有个网页能看到某个tree是否被测试过。Thomas Gleixner说现在0day system能够发出测试通过的邮件通知了，不过不是特别稳定。
Torvalds总结说，目前这个流程还是工作得很好的。不过还是有太多bug了，这是毋庸置疑的。过去几年中的代码改动速度一直比较稳定，这是件好事，这说明工作流程并没有成为社区的瓶颈，而说明我们确实没有太多需要改变的地方。不过大家也提出代码改动其实在不同子系统里面情况大不一样。BPF子系统的改动就非常频繁，Arm架构代码过去几年修改速度降了下来。
Greg Kroah-Hartman提到，在所有提交到mailing list上的patch里，只有2%没有收到任何反馈，这个数字比起过去的情况要好很多。Christoph Hellwig提出其实应该有更多patch可以直接忽略掉。他觉得Torvalds心情太好了，最好能回到以前那个总是怒发冲冠频繁说“no”的做法。Peter Zijlstra抱怨说他错过了那个过去的Linus，很可惜。
Dave Airlie问道，有没有一个review backlog，例如我们怎么能看出平均来说reviewer的响应时间是多长？Kroah-Hartman回答说有些子系统里面肯定是耗时很长的，目前还没有所有tree的review流程的统计信息。
Torvalds说他也会检查新patch的review流程，不过对某些tree他充分信任，基本上都不用看就可以直接pull合入，某些tree则需要对每个patch进行检查，这主要跟子系统的maintainer的工作方式有关。他提到，某些tree里面很多patch得到的review都是来自跟patch作者同一个公司的人，这种做法他很不喜欢。他也明白内部review还是流程中很重要的一环，不过他的建议是reviewer就不要给patch加Reviewed-by tag了。
讨论到internal review是否有价值，通常的看法是只有好处没有坏处的。不过Gleixner抱怨说他拿到过一些质量不高的patch都附带着5个Reviewed-by tag。Torvalds说这些只有内部review的patch一般都是在驱动程序子系统里，这些改动可能跟特定的硬件关系太密切了，所以其他人都没有兴趣看进去。他倒是提到Intel图形驱动子系统整体来说都很稳定，internal reviewer劳苦功高。
Olof Johansson认为作为reviewer，要想让大家信任你，最好的办法就是公开在mailing list上做review，而且指出一些真的问题。在讨论结束的时候，大家也建议说，如果公司内部管理层施加压力希望internal reviewer放过一些不太标准的代码，那应该能知会到maintainer，这样在mailing list上大家可以更仔细的审查一下。
[Your editor thanks the Linux Foundation, LWN's travel sponsor, for supporting travel to this event.]
全文完
LWN文章遵循CC BY-SA 4.0许可协议。
热烈欢迎转载以及基于现有协议修改再创作～
长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～
2536
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
