On Mon 2018-04-16 16:37:56, Sasha Levin wrote:
On Mon, Apr 16, 2018 at 12:30:19PM -0400, Steven Rostedt wrote:
On Mon, 16 Apr 2018 16:19:14 +0000 Sasha Levin Alexander.Levin@microsoft.com wrote:
Wait! What does that mean? What's the purpose of stable if it is as broken as mainline?
This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not.
In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable.
Honestly, I think that removes all value of the stable series. I remember when the stable series were first created. People were saying that it wouldn't even get to more than 5 versions, because the bar for backporting was suppose to be very high. Today it's just a fork of the kernel at a given version. No more features, but we will be OK with regressions. I'm struggling to see what the benefit of it is suppose to be?
It's not "OK with regressions".
Let's look at a hypothetical example: You have a 4.15.1 kernel that has a broken printf() behaviour so that when you:
pr_err("%d", 5)
Would print:
"Microsoft Rulez"
Bad, right? So you went ahead and fixed it, and now it prints "5" as you might expect. But alas, with your patch, running:
pr_err("%s", "hi!")
Would show a cat picture for 5 seconds.
Should we take your patch in -stable or not? If we don't, we're stuck with the original issue while the mainline kernel will behave differently, but if we do - we introduce a new regression.
Of course not.
- It must be obviously correct and tested.
If it introduces new bug, it is not correct, and certainly not obviously correct. Pavel