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.

@kernellogger @jann It's not just "unusual" that a cycle takes longer than 70 days, it has only happened twice in the last 15 years: 3.1 (slowed by the kernel.org compromise) and 4.15 (the meltdown/spectre release). It takes an event of that magnitude to slow things down at this point.

I'm not sure if we can realistically make the cycle shorter - some problems just take time to turn up and to be fixed.

@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

@corbet @jann

* 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

@jann why you asking? This was a really peaceful and easy release 😅

@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"

@jann I wish I could have got guard pages in to 6.12 but so be it ;)

Looking likely for 6.13 though.

I'm very glad we got the various cleanup patches in though...

Be fun to think my vma merge changes will be running on millions of devices

@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?

@brauner @kernellogger @corbet ooooof

@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...

@brauner @corbet @kernellogger @jann I'm doing most of my new code outside kernel and doing mostly fixes and reviews inside kernel ATM. The current cycle gives me opportunity to downscale and upscale my own contribution, not a lot but just enough.

Putting the release cycle too tight would make at first the life more difficult for independent kernel maintainers like me.

I've also noticed that the current window is great for big features, which need to fly for few weeks to get somewhat decent release quality. I might put a feature to Linus in the first PR and notice some actual problem at rc5/rc6. This would be a risk factor too.

@brauner @corbet @jann

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.

@Aissen @jann @kernellogger @corbet maybe bisect needs some config that tells it not to ever end up with having commit X without also having commit Y...

@vbabka @kernellogger @jann @corbet That's roughly (not exactly) what was discussed down in the thread, but I don't think it went anywhere.