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

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

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.