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

Sasha Levin Alexander.Levin at microsoft.com
Fri Sep 7 14:54:38 UTC 2018


On Thu, Sep 06, 2018 at 07:31:18PM -0700, Linus Torvalds wrote:
>On Thu, Sep 6, 2018 at 6:49 PM Sasha Levin
><Alexander.Levin at microsoft.com> wrote:
>>
>> You're saying that patches that come in during -rc cycles are more
>> difficult and tricky, and simultaneously you're saying that it's
>> completely fine taking them in without any testing at all. Does that
>> sound like a viable testing strategy?
>
>It sounds like *reality*.
>
>Note that I'm making the simple argument that there is a selection
>bias going on. The patches coming in are simply different.

Let's split this argument into two:

1. You argue that fixes for features that were merged in the current
window are getting more and more tricky as -rc cycles go on, and I agree
with that.

2. You argue that stable fixes (i.e. fixes for bugs introduced in
previous kernel versions) are getting trickier as -rc cycles go on -
which I completely disagree with.

Stable fixes look the same whether they showed up during the merge
window, -rc1 or -rc8, they are disconnected from whatever stage we're at
in the release cycle.

If you agree with me on that, maybe you could explain why most of the
stable regressions seem to show up in -rc5 or later? Shouldn't there be
an even distribution of stable regressions throughout the release cycle?

>What do you suggest you do about a patch that is a bug fix? Delay it
>until it has two weeks of testing? Which it won't get, because nobody
>actually runs it until it is merged?
>
>THAT is my argument. There _is_ no viable testing strategy once you're
>in the bug fix territory.

Sure, the various bots cover much less ground than actual users testing
stuff out.

However, your approach discourages further development of those bots. If
you're not going to use them properly then what's the point in investing
more effort into them.

If what you're saying is that it's pointless testing anything that comes
during late -rc windows then what reason I have to keep it in my
testing pipeline? I'll just drop all my upstream/-next testing and focus
on testing stable branches.

>> This is a *huge* reason why we see regressions in Stable.
>
>No.
>
>The *stable* people are the ones that were supposed to be the careful ones.
>
>Instead, you use automated scripts and hoover things up, and then you
>try to blame the development tree for getting stuff that regresses in
>your tree.

Yes, because stuff that regresses in my tree usually regresses your tree
as well.

This is also not about "hoovering": out of those 5 CoreOS issues, 2 came
in through David Miller's tree. David is probably the best person you
can have doing the net/ stable work and yet things still sneak in.

--
Thanks,
Sasha


More information about the Ksummit-discuss mailing list