New stable kernels to address build failures

[Posted March 5, 2026 by jzb]

Sasha Levin has announced the release of the 6.12.76, 6.6.129, and 6.1.166 stable kernels. These releases address a regression reported by Peter Schneider; Levin said that an upgrade is only necessary for those who have observed a build failure with the 6.12.75, 6.6.128, or 6.1.165 kernels.

to post comments

no codified stable release process?

Posted Mar 6, 2026 0:07 UTC (Fri) by rolexhamster (guest, #158445) [Link] (6 responses)

Lots of red flags going off here.

Sasha Levin writes:

> Yup, sorry. I don't have as much automation as Greg does,
> so many of the steps were manual...

and also writes:

> Releasing yesterday's tree was (my) human error: I don't have as much
> automation and scripting as Greg does, so many of the steps I've taken were
> manual and prone to errors. I'm working on improving this workflow on my end.

For the lack of a better word, this all seems amateurish, which is definitely ill fitting for "stable" kernel releases.

Obvious but pertinent questions:

Why isn't Sasha using Greg's workflow?
Where is the shared tooling and codified release process for the stable releases?

no codified stable release process?

Posted Mar 6, 2026 7:15 UTC (Fri) by aaronmdjones (subscriber, #119973) [Link] (5 responses)

This is the second time in recent memory that they've had to release a new 6.6 kernel solely to revert a commit introduced in a prior one (6.6.129, 6.6.126) that was causing build failures or boot errors. The other one (6.6.125, which 6.6.126 fixed) was released by gregkh, so it doesn't seem to matter much who releases them; clearly, more testing for a supposed stable long-term kernel is required before letting it out into the world.

beyond process

Posted Mar 6, 2026 19:52 UTC (Fri) by fratti-co (subscriber, #175548) [Link]

kernelci's dashboard will already show you that stable releases have more testing than mainline: https://dashboard.kernelci.org/tree

One problem is that it's not always easy to know whether every line of C you've modified with a diff has seen a compiler zip through it, I think. From what I can tell, KConfig does not make it easy to get from a .c or a .diff to a list of KConfig symbols that need to be enabled in order for that .c/.diff to get built.

Having more automated testing fed into kernelci would definitely help as well; theoretically anyone can set up an automated lab for this. I plan to for some of my hardware when I get the time and energy to do so.

no codified stable release process?

Posted Mar 7, 2026 21:59 UTC (Sat) by pschneider1968 (guest, #178654) [Link] (1 responses)

> clearly, more testing for a supposed stable long-term kernel is required before letting it out into the world.

So feel free to join us and help with testing! It's true that the pool of testers is way too small, and that we need more test coverage.

Looking forward to see your Tested-By in the next stable RC cycle.

no codified stable release process?

Posted Mar 8, 2026 22:58 UTC (Sun) by ryannestone (subscriber, #182659) [Link]

The Linux Foundation's assets has increased by twenty million dollars according to the last two 990 forms. In the last five years, revenue has gone up one hundred million dollars. Linux is not a small open source project and hasn't been for some time. Asking for more testers is baffling considering that the original criticism is about project mismanagement where stable is a misnomer. A project that could on its own afford thousands of computers for automated testing.

no codified stable release process?

Posted Mar 11, 2026 12:45 UTC (Wed) by ATLief (subscriber, #166135) [Link] (1 responses)

This is also the 3rd regression hotfix for 6.12 in the last 2 months. Versions 6.12.64 and 6.12.69 were released by Greg while 6.12.74 was released by Sasha.

no codified stable release process?

Posted Mar 11, 2026 12:46 UTC (Wed) by ATLief (subscriber, #166135) [Link]

Comment hotfix: s/6.12.74/6.12.75/g