Policy: "routed through for-next, ... unless introduced in the most recent cycle"
Thorsten Leemhuis <[email protected]> Tue, 28 Jul 2026 08:10:48 +0200
| Newsgroups | dev.linux.lists.regressions,org.kernel.vger.linux-kernel,org.kernel.vger.platform-driver-x86 |
|---|---|
| Message-ID | <[email protected]> |
Hi Ilpo! I stumbled about a few messages of yours where you apply a commit for later mainlining were you wrote this: > FYI [if applicable to your patch], as per Linus' policy change, also > fixes are mostly routed through for-next unless the fix is for a > commit introduced in the most recent cycle or is clearly a regression > fix. Could you point me to the source of "per Linus' policy change"? I really wonder if I missed something, as from what I know Linus wants fixes for regressions in all recent released merged quickly (e.g. in the current cycle), unless very dangerous or so. My knowledge is among others based on this statement from Linus: https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ To quote: """ And yes, I do consider "regression in an earlier release" to be a regression that needs fixing. There's obviously a time limit: if that "regression in an earlier release" was a year or more ago, and just took forever for people to notice, and it had semantic changes that now mean that fixing the regression could cause a _new_ regression, then that can cause me to go "Oh, now the new semantics are what we have to live with". But something like this, where the regression was in the previous release and it's just a clear fix with no semantic subtlety, I consider to be just a regular regression that should be expedited - partly to make it into stable, and partly to avoid having to put the fix into _another_ stable kernel.. """ Is there something newer that invalidates this? Ciao, Thorsten