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

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

[Thorsten Leemhuis]

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

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

[Ilpo Järvinen]

On Tue, 28 Jul 2026, Thorsten Leemhuis wrote:

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

Hi Thorsten,

What I'm referring to is this policy change:

https://lore.kernel.org/lkml/CAHk-=wjt1NiKOdyAMz_DT7NmZ++SizPOhRSi492ukdTnpDzHQw@mail.gmail.com/


Perhaps it's just misunderstanding of my wording. My note says "unless". 
So to qualify for fixes as per the new policy the fix has to be either 
a) for something recently introduced (merged in this cycle) or b) a 
proved/tested regression fix to "any" version (not some theoretical 
regression somebody found with a tool or AI or reading the code; "any" is 
somewhat subjective when it comes to very old regressions).

The point of my note in that thank you email is not to set any policy but 
to just explain why less patches are these days merged through fixes 
branch. In pdx86 domain this largely relates to certain kind of patches:

- .probe rollback path fixes (a platform driver probe can certainly fail, 
but does it in practice?)
- .remove fixes (well yeah, removing a platform driver is technically 
possible, but why to do that?)
- new HW additions which previously went through fixes branch

Those issues tend to be quite old so they are not very critical and all 
these can easily wait a few weeks more.

I did differentiate based on criticality and complexity of a "fix" towards 
the end of cycle even before Linus sent that note but now I'm just making 
things easier to me and push most stuff through for-next (which leaves me 
less conflicts to deal with as well). That being said, Rafael Wysocki 
happened to add ACPI NULL checks to platform drivers (force match corner 
case) in that very -rc linked above, so perhaps I'm in part of the reason 
why Linus got tired of seeing so many "fixes". :-)


The way I read your email is that your main concern is that according to 
the new policy, only very recent regressions should be addressed through 
fixes, but that's not what my note (nor Linus, AFAICT) is saying.

I hope the link and explanation helped.

-- 
 i.

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

[Thorsten Leemhuis]

On 7/28/26 13:39, Ilpo Järvinen wrote:
> On Tue, 28 Jul 2026, Thorsten Leemhuis wrote:
>> 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/
> [...]
> What I'm referring to is this policy change:
> 
> https://lore.kernel.org/lkml/CAHk-=wjt1NiKOdyAMz_DT7NmZ++SizPOhRSi492ukdTnpDzHQw@mail.gmail.com/
> 
> Perhaps it's just misunderstanding of my wording. [...]

Yeah, words is not as clear as math, and even the latter sometimes
leaves room for interpretation if you are not careful. :-D

Many thanks for the detailed explanation, now I understand your intend
better. It's just that "people queue fixes for recently user-reported
regressions in for-next instead of mainlining them quickly" was one of
the biggest problems I saw when I started regression tracking. It got
better, but there is still a lot of room for improvement, which is why
that short note got me wondering what the exact meaning was. But seems
we are mostly in alignment here.

Ciao, Thorsten