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