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.
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.
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.
Thanks, Vlastimil
Also since the patches are AFAIU dependent on each other, sending them separately makes the mainline development process more difficult, as evidenced by the later revisions having to add notes in the diffstat area etc. This would go against the goal that stable process does not add extra burden to the mainline process, no?
If they are dependent on each other, that's the creator's issue, not the maintainer's issue, no? :)
Submit the bug fixes, get them merged, and then submit the new features.
thanks,
greg k-h