backport remaining patches
See original GitHub issuefrom @rbtcollins : Biggest outstanding thing is to fixup the back port automation now python is in git. It may be trivial in fact.
This lives in /tools
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (1 by maintainers)
Top Results From Across the Web
What is Backporting? The Process & How It Works | CrowdStrike
Backporting is when a software patch or update is taken from a recent software version and applied to an older version of the...
Read more >Backport a patch | Drupal.org
Goal: Backport a committed patch to an earlier branch of a project. Explanation: Patches (and merge requests) for software changes are normally committed...
Read more >Bug 11069 - The Samba-Bugzilla
The Samba-Bugzilla – Bug 11069 Backport remaining performance patches for vfs_glusterfs to 4.2/4.1 Last modified: 2015-01-29 20:11:13 UTC.
Read more >1397697 – Backport remaining kvm_stat patches from the kernel to ...
Let's backport the remaining upstream patches (from the kernel to QEMU). These should include the following kernel commits: f0cf040 tools: kvm_stat: ...
Read more >Backporting Security Patches of Web Applications: - USENIX
Here are the numbers of remaining patches and target versions after each step. In the first step, SKYPORT verifies that 111 out of...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

IMO it’s good to have each commit from upstream land here instead of a single commit. If there is a regression in the backport not covered in tests then having separate commits would help in bisecting.
Do I understand correctly that the backporting is done manually?
If yes, then why not simply generate patch from the upstream git repository, e.g. by running:
And then use the existing script:
I have tried it now and it seems to mostly work. I am not sure which version is the
previous_patch_revision, so I have usedv3.7.0. The result was a patch which applied mostly cleanly, except for a few hunks that need manual resolving.