Re: Improving Linux Commit Backporting

["gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>]

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