最近在 lkml.org 上看到Linus发布的一个信息，挺有意思的，我看了内容，然后根据自己的理解展示给大家看看，如果有不对的地方欢迎指正。

好的，5.10内核发布了

我真希望在圣诞节来的最后一个星期没有那么多破事，现在还有很多该死的补丁需要合并， 还有几个补丁，在最后时间点都不能修复，我只能reverts了「revert是git中用来移除提交的」。

不过，不管啥事情，我还是要给自己多一周的假期，哈哈，事情很顺利。

驱动程序真的是内核里面的一大块了，这里想说个事情，以前存在的一些老得要死的驱动，为什么不从内核中删除掉呢？

到处都是一些零星的补丁，包括：网络、体系结构、文件系统、工具等等。

提交的补丁增加了一些简短的信息。and scanning it gives a good idea of what kind of things are there 「这句话没看清楚表达啥，大概意思就是扫描这些补丁的提交commit，可以看到这些补丁的提交信息。」

这些补丁修补的都不是什么严重的问题，大部分都是一些很小的补丁，最大的一个补丁是修改pincontrol 驱动中的pin 映射定义。

显然了，这也意味着5.11的合并窗口将从明天开始。我已经有几个请求请求待处理

—— 你们知道你们是谁，并谢谢你们。

我们每个人都知道要在5.11的内核版本合并patch这件事情，但是我们只有一个星期就要过圣诞节了，而且，我们每个人都想度假，都想回家吃火鸡，都想在家里喝喝啤酒，享受一下生活。

因为这样的原因，我对于合并代码要格外的严格，真担心有人不好好审核代码，提交了一个bug到内核里面。

现在，我确定大家也都想去度假，而且我很惊讶为什么没有提早提交并审核这些补丁。因此，我认为整个 “你们发送给我的一切都应该已经完成” 是我们都可以签署的「把锅踢给提交者，觉得提的代码就应该是确保没有问题的」。

「言外之意 —— 老子是合并代码的，不是帮你们检查代码的」

但是正是由于这个时机，我对第二周出现的任何新的延期请求都不重视了，我希望可以处理完一些积压请求，当然，我不想在处理积压的事情同时，又有一些其他的工作砸过来。

因此，如果某个提交没有在linux-next中，并且你因为没有完成而没有向我提交，基本上应该计划不将它放入5.11版本中。不过如果你在之后修改完成，会在下一个版本发布，不用担心。

这也是我们技术上的规则，只是我平时没有那么固执，一般情况下，如果提交的补丁没有大的问题，我都会让它合并。这次我有充分的理由来解释为什么我要强制执行**“最好在合并窗口打开之前就已经做好准备**”的规则。—— 「因为老子想度假」

本来这些事情就是加负荷的工作，如果这些工作因为度假被搁置了，我可能延迟发布rc1来把这些进度追赶上来，但我不希望需要这样做。但是即使确实工作被搁置了，也不意味着我在圣诞节度假后就接受pull 请求，就会马上响应你们的提交。

当然了，如果有一些提交真正的解决了问题，并且让内核得到改善，就不应该让这个规则限制它，老子在度假之后，就会马上合并到内核中。

莱纳斯

— — 以下为英文原文

Ok, here it is - 5.10 is tagged and pushed out.I pretty much always wish that the last week was even calmer than it
was, and that's true here too. There's a fair amount of fixes in here,
including a few last-minute reverts for things that didn't get fixed,
but nothing makes me go "we need another week". Things look fairly
normal.It's mostly drivers - as it should be - with a smattering of fixes all
over: networking, architectures, filesystems, tooling.. The shortlog
is appended, and scanning it gives a good idea of what kind of things
are there. Nothing that looks scary: most of the patches are very
small, and the biggest one is fixing pin mapping definitions for a
pincontrol driver.This also obviously means that the merge window for 5.11 will start
tomorrow.  I already have a couple of pull requests pending - you guys
know who you are, and thank you.The most notable thing about the 5.11 merge window will be obvious to
anybody who takes a look at the calendar: realistically speaking, we
only have one week before the holidays are upon us, and everybody is
much too distracted. That means that I will be particularly strict
about the whole "the merge window is for things that are ready
*before* the merge window starts".Now, I'm sure you all want to go off for holidays too, and I'm
actually surprised that I don't have more early pull requests pending.
So I think the whole "everything you send me should have already been
done" is something we can all sign up for. But exactly _because_ of
the timing, I will simply not be very interested in any new late pull
requests that come in the second week of the merge window: I expect to
still be handling some of the backlog that week _anyway_, but I
certainly do not want to get more of it.So if it's not already in linux-next, and if you aren't happy sending
it in this upcoming week because it's not quite done yet, you should
basically plan on not getting it into 5.11 at all. There will be
releases after that one, don't worry.This has _technically_ been the rule before too, it's just that I
generally haven't been all that hard-nosed about it, and have let
things slide if it wasn't _too_ egregious. This time around I have
fairly clear reasons why I'm just going to enforce that "it had better
be ready before the merge window even opened" rule.If my overflow handling then ends up being interrupted by the
holidays, I may end up delaying rc1 just to catch up, but I hope and
expect that that won't even be needed. We'll see. But even if it does
happen, it most certainly will _not_ mean that I will take pull
requests that came in after the holidays.Actual fixes that would be valid even outside the merge window are
obviously not affected by that rule.Linus

推荐阅读：

专辑|Linux文章汇总

专辑|程序人生

专辑|C语言

我的知识小密圈