#Linux 7.1-rc5 is out:

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

""To the surprise of absolutely nobody by now, rc5 is pretty big. Quite a bit bigger than rc5's have traditionally been.

I'm not entirely happy about it - most of this is totally trivial stuff to random drivers, which obviously makes it all less scary, but at the same time I'm really not convinced the churn is worth it at rc5 time. These things are "fixes", sure, but at the same time a lot of them are simply so irrelevant that I think they'd be better off in a linux-next tree and get merged during the merge window.

So I think I'll start being a bit more hardnosed about this kind of unnecessary churn this late in the game. We are supposed to look for *regressions*. Non-critical fixes to long-standing issues are simply not appropriate for this late in the release cycle.

End result: this is too big, and this is the heads-up that I'll be pushing back on pointless pull requests with fixes that just aren't that important. And yes, several of these series were triggered by AI code review.

Because fixes or not - and trivial or not - these kinds of large rc weeks are *not* conducive to long-term stability. Trivial fixes may be trivial, and have a pretty low chance of causing problems, but "low chance" is still not "zero chance".

So people: start looking closer at your pull requests, and ask yourself: "Is this really a regression or serious enough that it shouldn't just go into the development pile?".

Linus""

#kernel #LinuxKernel

@kernellogger lots of wise words that the stable maintainers won't heed.

@vbabka yeah; it's a huge topic, so please allow me to just focus on one detail of it I care about:

I once again wonder if we need to flag regression fixes with a special tag so that the stable team (as well as reviewers and maintainers) can differentiate them from other changes that fix something and handle them differently.

@kernellogger maybe? First the stable maintainers would need to care to differentiate. And maybe Fixes: tag that points to a commit from the recent merge window or the previous version is a strong enough signal?

@vbabka @kernellogger FWIW; I have seen AUTOSEL picking up patches from me that were NOT a fix. :/

@ffmancera @vbabka well, as I said earlier, huge topic. But allow me to play devils[1] advocate for a moment:

AUTOSEL is made to locate changes that fix something, but accidentlly lack a "Fixes:…" or "<CC: stable@…" tag - but like every such tool it will have false positives.

Are there too maybe false positives? No idea.

Do we need such a tool at all? From a brief look it feels like it finds quite a few of those, so it might be worth it. Wonder, though, if we better might be running such a tool so the right tags can be added before they hit mainline. But even then some will always slip through.

Sigh. It's complicated. 😕

[1] for the record, I feel sympathies with both camps here (why the stable-team works like it does vs. people complaining about how it works)

@kernellogger @vbabka My main issue with stable kernel is how it is perceived from distributions.

Like the discussion we had in Fedora about how packaging an LTS kernel using a stable variant would help to avoid breaking OOT modules..

At the end, sure stable is not supposed to be adding new feature but it is also not preserving kABI which is what might break a OOT module if I am not wrong..

@ffmancera @kernellogger well that's another different thing and nobody upstream cares about OOT modules and preserving their ABI, including stable. And I don't have any problem with that part.

@kernellogger @ffmancera I think there's a difference between suggesting forgotten fixes, and mindlessly applying everything AUTOSEL flags. But seems thanks to @axboe the latter is now paused :) https://lore.kernel.org/all/ahHCfBzDuCRCdTDB@laps/

@ffmancera @vbabka

Wonder how much of the pain Fedora users deal with due to OOT modules it due to aspects specific to the Fedora world that could fixed. We for example had pre-compiled module package 15 years ago -- so all that was missing was "make dnf not update the kernel if the required OOT module rpms are missing". Makes me wonder if Arch and Tumbleweed handle that better than Fedora.

And nvidia is now using GPLed module for modern cards, so it became easier to fix API incompatibilities in time for a kernel update.

I consider regressions when upgrading from the previous to the latest stable series the bigger problem – even before regressions within a stable-series.

@vbabka @kernellogger @ffmancera @axboe Good. And world will be better if that is not restarted.

@kernellogger @ffmancera @vbabka this would be better if developers had to make an explicit "is this a fix" decision when sending a fix; which would be easiest to enforce in a more centralized system, but I guess checkpatch is the next best thing the kernel has?
like, require a commit to have the tag "No-Fix", or "Fixes: " with a No-Stable tag, or "Fixes: " with a stable backport line, or something like that...

@jann @kernellogger @ffmancera @vbabka Considering how poor developers are at expressing WHY they are doing that change/commit, I don't have big hopes on them being able to express that something is a fix.