Policy: "routed through for-next, ... unless introduced in the most recent cycle"

From: Thorsten Leemhuis

Date: Tue Jul 28 2026 - 02:14:38 EST


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@xxxxxxxxxxxxxx/

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