Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

Jiri Kosina
2018-04-16T20:33:16Z

On Mon, 16 Apr 2018, Linus Torvalds wrote:

> The ones who should matter most for that discussion is the distros,
> since they are the actual users of stable (as well as the people doing
> the work, of course - ie Sasha and Greg and the rest of the stable
> gang).
>
> And I suspect that they actually do want all the noise, and all the
> stuff that isn't "critical". That's often the _easy_ choice. It's the
> stuff that I suspect the stable maintainers go "this I don't even have
> to think about", because it's a new driver ID or something.

So I am a maintainer of SUSE enterprise kernel, and I can tell you I
personally really don't want all the noise, simply because

(a) noone asked us to distribute it (if they did, we would do so)
(b) the risk of regressions

We've always been very cautious about what is coming from stable, and
actually filtering out patches we actively don't want for one reason or
another.

And yes, there is also a history of regressions caused by stable updates
that were painful for us ... I brought this up a multiple times at
ksummit-discuss@ over past years.

So with the upcoming release, we've actually abandonded stable and are
relying more on auto-processing the Fixes: tag.

That is not perfect in both ways (it doesn't cover everything, and we can
miss complex semantical dependencies between patches even though they
"apply"), but we didn't base our decision this time on aligning our
schedule with stable, and so far we don't seem to be suffering. And we
have much better overview / control over what is landing in our enterprise
tree (of course this all is shepherded by machinery around processing
Fixes: tag, which then though has to be *actively* acted upon, depending
on a case-by-case human assessment of how critical it actually is).

> Because the bulk of stable tends to be driver updates, afaik. Which
> distros very much tend to want.

For "community" distros (like Fedora, openSUSE), perhaps, yeah.

For "enterprise" kernels, quite frankly, we much rather get the driver
updates/backports from the respective HW vedndors we're cooperating with,
as they have actually tested and verified the backport on the metal.

> The critical stuff is hopefully a tiny tiny percentage.

But quite frankly, that's the only thing we as distro *really* want -- to
save our users from hitting the critical issues with all the consequences
(data loss, unbootable systems, etc). All the rest we can easily handle on
a reactive basis, which heavily depends on the userbase spectrum (and
that's probably completely different for each -stable tree consumer
anyway).

This is a POV of me as an distro kernel maintainer, but mileage of others
definitely can / will vary of course.

Thanks,

--
Jiri Kosina
SUSE Labs