Backporting is a chore. I want to make it easier for me and especially for most of you. I'd like to handle most of the backporting so that most of you don't have to, at least to branch_10x. With automation in place, I personally won't spend much time on it either.
If we just consider branch_10x for now... addressing more complicated cases later... We have a `/dev-tools/scripts/cherrypick.sh` script that consumes git commits you pass in, then cherry-picks backports, runs tests, and even pushes if you tell it to. Although it doesn't do merge conflicts well... that should be rare if we scope this conversation to branch_10x and if we imagine most backports are done by one person (thus creating more linearized changes). I wrote a simple script to identify first line commit messages present on one branch (say main) but aren't on a target branch. I can add it to our scripts. I have an AI skill that works with cherrypick.sh and it checks the Jenkins build status of 3 important jobs. It can also address merge conflicts. It's easy for me to tell Claude to use the commits identified from the other script. A missing mechanism is a way to identify which commits *should* be backported. Nearly all commits on main should be backported but over time that will diverge some. And I'd like to grow the backport mechanism for other branch backporting. If we limit the scope of my back-porting service to only PRs (sorry Hossman), then we can imagine using GitHub tags or "Milestones", like "10.x". Anyway... not sure if others have thought of or seen solutions for this overall. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
