On Thu, Apr 03, 2025 at 01:15:28PM +0000, Manthey, Norbert wrote:
Dear Linux Stable Maintainers,
while maintaining downstream Linux releases, we noticed that we have to backport some patches manually, because they are not picked up by your automated backporting. Some of these backports can be done with improved cherry-pick tooling. We have implemented a script/tool "git- fuzzy-pick" which we would like to share. Besides picking more commits, the tool also supports executing a validation script right after picking, e.g. compiling the modified source file. Picking stats and details are presented below.
We would like to discuss whether you can integrate this improved tool into into your daily workflows. We already found the stable-tools repository [1] with some scripts that help automate backporting. To contribute git-fuzzy-pick there, we would need you to declare a license for the current state of this repository.
There's no need for us to declare the license for the whole repo, you just need to pick a license for your script to be under. Anything that's under a valid open source license is fine with me.
That being said, I did just go and add SPDX license lines to all of the scripts that I wrote, or that was already defined in the comments of the files, to make it more obvious what they are under.
To test backporting performance, we tried to backport stable-candidate patches from 6.12 to 6.1. Specifically, on tag 6.1.125 we executed the command stable show-missing-stable v6.12.12..v6.12.17 to collect patches considered for backporting. This results in 431 backport candidates. When using git-fuzzy-pick, we can pick 9 patches more than with default cherry-picking. All modifications have been validated by attempting to build the object files of the modified C source files with make using the kernels “allyesconfig” configuration.
196 Cherry-picked with --strategy=recursive --Xpatience -x 1 Applied with patch -p1 ... --fuzz=1 8 Applied with patch -p1 ... --fuzz=2
Please let us know how to best share the tool with you! Long term, we would like to integrate it into your backporting workflow, so that more kernel commits can be applied automatically.
A long long time ago I used to apply patches with a whole lot of fuzz in a semi-automated way much like this, but things slipped through all the time. So now, if we have a failure, I throw it back to the developers/maintainers involved and let them and/or the community deal with it if they want to have the commit backported. That way they can test and manually verify that the backport is correct.
So no, I don't recommend auto-fuzz-forcing any commits WITHOUT manually looking and verifying and checking and taking responsibility for the backport being correct. Right now we are full of work just keeping up with 40 commits a day in the stable trees. If others wish to help out, we are more than willing to take the backports that have been submitted to us, and we now can handle them directly from the mailing lists even easier than before, with Sasha's bot reporting any potential problems, and my local scripts that properly apply them to the specific queues in a "very few" key-stroke command from my email client.
So in summary, I'm more than willing to take a patch that adds your tool to our repo, for others to use, but I don't want to be the one responsible for running it. I want others to take that responsibility if they care about applying those patches to older kernels properly, as it's the companies that care about those kernels that should be the ones helping us out the most, instead of asking others to do this work for them, don't you think? :)
thanks,
greg k-h