On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > > > Hi all, > > > > > > > > > > we are considering dropping upstream support for kernel versions < 4.4. > > > > > Would this be a problem for anyone? (*). > > > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel > > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > > > It seems Civil Infrastructure Platform (a project under the Linux > > > Foundation) still uses 4.4 [1]. > > > > Yes, but they are not going to be updating to a newer version of > > systemd, right? > > > > And they are going to be "supporting" that for 20+ years. If they want > > to do something crazy like this, make them handle supporting code that > > is older than 6+ years to start with. That's not the community's issue, > > that's the companies that demand such crazy requirement's issue. > > That's why I (we) asked the question on the list. If people are compling > systemd on such old systems, or even older, we want to know about it. > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9, > > > and after that Buster has 4.19. > > > > 4.9 is fine, and is supported by kernel.org until next year as seen > > here: > > https://kernel.org/category/releases.html > > > > I wrote "4.9" above, not "4.19" :) > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up. > > Zbyszek Let's do 4.4 at most please - what's on kernel.org is not really that important, as real usage is downstream from there anyway. What matters for core compatibility is what's the oldest in a reasonable environment, and we know that's at 4.4. It's already quite a bump from the current 3.13. At least according to our documentation it wouldn't save us much anyway, as the biggest leap is taking cgroupv2 for granted, which requires 4.1, so it's included regardless. Unless there's something undocumented that would make a big difference, in practical terms of maintainability? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
