Re: Improving Linux Commit Backporting

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

On Mon, Apr 07, 2025 at 07:26:59AM +0000, Manthey, Norbert wrote:
> On Thu, 2025-04-03 at 15:51 +0100, gregkh@linuxfoundation.org wrote:
> ...snip ...
> > On Thu, Apr 03, 2025 at 02:57:34PM +0100, gregkh@linuxfoundation.org wrote:
> > > On Thu, Apr 03, 2025 at 02:45:35PM +0100, gregkh@linuxfoundation.org wrote:
> > > > On Thu, Apr 03, 2025 at 01:15:28PM +0000, Manthey, Norbert wrote:
> ...snip...
> > > > > 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.
> Thanks!
> > > 
> > > Wait, you should be looking at the scripts in the stable-queue.git tree
> > > in the scripts/ directory.  You pointed at a private repo of some things
> > > that Sasha uses for his work, which is specific to his workflow.
> I had a look at those scripts too. Looks like you use git am, and abort in case this operation
> fails.

We only use 'git am' to apply the quilt series to the tree when doing
a release (the final one or the -rc ones).  We use quilt to manage
everything in the stable-queue.git tree as that provides us with the
needed flexibility.

> > Also, one final things.  Doing backports to older kernels is a harder
> > task than doing it for newer kernels.  This means you need to do more
> > work, and have a more experienced developer do that work, as the nuances
> > are tricky and slight and they must understand the code base really
> > well.
> > 
> > Attempting to automate this, and make it a "junior developer" task
> > assignment is ripe for errors and problems and tears (on my side and
> > yours.)  We have loads of examples of this in the past, please don't
> > duplicate the errors of others and think that "somehow, this time it
> > will be different!", but rather "learn from our past mistakes and only
> > make new ones."
> We understand. We might make the tool available to help simplify the human effort of backporting. To
> make this more successful, is there a way to identify the errors and learnings you mention from the
> past? Avoiding them automatically early in the process helps keeping the errors away.

Don't ignore fuzz, manually check, and verify, everything.

good luck!

greg k-h