On Tue, Apr 22, 2025 at 03:07:54PM +0200, Vlastimil Babka wrote:
On 4/22/25 12:50, Greg KH wrote:
On Tue, Apr 22, 2025 at 12:20:42PM +0200, Vlastimil Babka wrote:
I admit it's surprising to see such a request as AFAIK it's normally done to mix stable fixes and new features in the same series (especially when the patches depend on each other), and ordering the fixes first and marking only them as stable should be sufficient. We do that all the time in -mm. I thought that stable works with stable marked commits primarily, not series?
Yes, but when picking which "branch" to apply a series to, what would you do if you have some "fix some bugs, then add some new features" in a single patch series? The one to go to -final or the one for the next -rc1?
As a maintainer I could split it myself.
You must not have that many patches to review, remember, some of us get a few more than others ;)
I see a lot of bugfixes delayed until -rc1 because of this issue, and it's really not a good idea at all.
In my experience, most of the time these fixes are created because a dev:
- works on the code to implement the feature part
- while working at the code, spots an existing bug
- the bug can be old (Fixes: commit a number of releases ago)
- wants to be helpful so isolates the fix separately as an early patch of
the series and marks stable because the bug can be serious enough in theory
- at the same time there are no known reports of the bug being hit in the wild
In that case I don't see the urgency to fix it ASAP (unless it's e.g. something obviously dangerously exploitable) so it might not be such a bad idea just to put everything towards next rc1.
Yes, but then look at the huge number of "bugfixes" that land in -rc1. Is that ok or not? I don't know...
This very thread seems to be a good example of the above. I see the later version added a Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") which is a v5.2 commit.
Agreed, but delaying a known-fix for weeks/months feels bad to me.
thanks,
greg k-h