[Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

[Linus Torvalds]

On Fri, Sep 7, 2018 at 8:52 AM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> See? I'm just arguing that there can be correlations with problems
> that are much more likely than "it spent only 3 days in next before it
> got into mainline".

Btw, another source of these kinds of non-causal correlations might be
just how people work.

For example, for me, the merge window is my busiest season by far
(obviously).  I try to schedule my time off to coincide with late in
the rc, because it's just quieter: at that point I'm mostly waiting
for stuff.

But that's actually _supposed_ to be just me (and maybe Stephen Rothwell).

And for maintainers, it can be the exact reverse. In Vancouver Greg
said that normally, for him, the merge window is when he can take a
break, because the bulk of his work is the "leading up to merge
window" time, since that's when he works with people to set up the
branches for the next merge window.

So *during* the merge window, the development tree actually looks
really busy, but maintainers may be taking it easy and are basically
in the "my work is done, now I'm waiting for reports". So exactly the
reverse of my situation, and exactly the reverse of what it *looks*
like in the development tree.

Everybody thinks that the merge window is when all the work goes on,
but in reality, the reverse can true. The merge window and the early
rc's can (and almost certainly _should_) be the time when a maintainer
takes a breather.

And guess what? Last merge window was the exception to that rule. With
the timing of L1TF, we had the stable tree work happening on patches
that were merged during the merge window.

And honestly, I'd not be surprised at all if the usual "stable patches
that came in rc5+ caused more problems" is reversed this time around.
We already know that this time around, we had tons of issues with the
stable tree with patches that were merged in mainline during the merge
window.

Of course, there will - once again - be a very strong correlation with
"it wasn't in linux-next". But this time the correlation won't be with
"rc5+".

And - once again - the correlation is real, but it's incidental to the
*real* causal relationship. It's just that - correlation. The real
causality just happened to be different this time, and so you won't
find the usual "rc5+" correlation, but you will still find the "less
time in linux-next" one.

But normally, I'd actually expect that "late rc" is exactly when
maintainers are doing most of their work, and then they see "oh, this
patch needs to go in *now*, so I'll send it to Linus in a fixes pull".

So none of my arguments are "testing is bad". I really don't want it
to appear that I make that argument.

But honestly, my reaction remains that "late rc fixes are more likely
to cause nasty problems" sounds very natural to me, and sounds largely
independent of the testing issue.

           Linus