so what will be the next Linux LTS? 6.12 or 6.13? I guess there might be just barely enough time left for a 6.13 release this year?
@jann IIRC, 6.13 is scheduled to release mid-January. If that holds, 6.12 will be the LTS kernel.
@jann 6.12 is the next Longterm kernel, as it's highly unusual when a devel cycle is not 63 or 70 days[1]. 6.13 thus will be out on January 20th or 27th – or one week later each, if we for some reason get a 6.12-rc8.
[1] see screeshot of https://docs.google.com/spreadsheets/d/1_yH7lFmZxAoSWrtsd8tGu3befG4zIcMnytB1ml4pQQM/edit?gid=1170907286#gid=1170907286&range=A130 below
@kernellogger oh, that's a nice graphic. Somehow I thought the release cycle was shorter...
@jann not a big fan of such graphics or charts myself, but yes, sometimes they really help make things obvious and/or easy to grasp.
Up to some point at least. Because in this chart it's not easy to see that we have more 63 day cycles these days (it used to be round about 50/50)
@jann ohh, and btw, I think we could even make they cycle shorter if we wanted to. Some "you have to have your PR ready by the third day of the merge window" rule coupled with reverting things more quickly could reduce the cycle by one to three weeks I suspect, if we wanted to.
@corbet @kernellogger @jann after so many years I am sure some manager are depending hard on the cycle length. Don't break the 'user 'application'! :)
@wagi @corbet @kernellogger @jann you know, if the kernel community decides that the ‘user application’ has been doing it wrong, then just f*k them
* how many of those problems only turn up so late because there are even kernel developer that fear testing -rc1 releases since they were burned (for example with 5.12-rc1 – or which version was it that got the "DONTUSE" tag?)
* some subsystems are always ready when the merge window opens, others are not and often send their PR at the end – there might be room for improvement
* a more offensive policy "revert, try next or overnext cycle again" could help, too (if we wanted to)
@kernellogger @corbet oof, wow, I hadn't seen that story before.
https://lore.kernel.org/all/CAHk-=wjnzdLSP3oDxhf9eMTYo7GF-QjaNLBUH1Zk3c4A7X75YA@mail.gmail.com/
swap pages splattered all over the disk in some configs? ouuuch.
the idea that for some time after that, you could have even realistically bisected into that by random chance is pretty scary
@ljs I was just curious from the perspective of "is this going to be the cutoff point for what features moderately conservative distros ship next year, and what features will land in phone kernels in however-much-time-in-the-future that takes"
@corbet @kernellogger @jann There's also the question what the value would be of shortening the release cycle. The pace is already quite high from a maintainers perspective.
@jann @kernellogger @corbet That rc crashed my laptop by corrupting my disk and specifically my /boot. It was also the worst because I thought a very big change I had landed that cycle had caused disk corruption. I've never been happier when I figured out it wasn't my changes and when I had recovered my laptop.
@jann @kernellogger @corbet you could still bisect into it, right?
@Aissen @kernellogger @corbet I guess probably? But at this point it's probably outside the kinda range you'd normally bisect over unless you're chasing a bug that may have existed for years already...
Yeah, it was just thinking out loud along the path of "could we do it" – I don't care much about the cycle length.
At the same time I wonder how much the fear of change is a factor here and if there would be upsides we just don't see.
Still remember when the current model started in the 2.6 days and a lot of people (incl. some developers) feared it would kill Linux; same for Firefox when it started their rolling model and shorted the cycle a few years ago.
@vbabka @kernellogger @jann @corbet That's roughly (not exactly) what was discussed down in the thread, but I don't think it went anywhere.