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