I've iterated a bit on this project. I have some scripts & AI "skills".
In GitHub, there are now 3 milestones -- 9.x, 10.x, 11.x. A PR can have at most one milestone, it's mutable, and it can be set by committers. I haven't checked if contributors can set it; hopefully not. *If* you set the milestone (to < 11.x) -- an opt-in signal, and *if* you have not *yet* backported a PR, then I will tend to backporting it to 10.x, maybe 9.x too if applicable. Each change must pass several important Jenkins CI jobs and a GitHub-based Docker CI job to confirm the PR built successfully. Those are daily jobs, by the way, so a change can be further delayed, especially if any of those jobs aren't happy. I initiate this backporting automation manually when I feel like it -- perhaps every other day or so for 10.x, maybe weekly for 9.x. I haven't done it for 9.x yet. Note that if you view your PR then you will eventually see commit references linked in the timeline, thereby seeing when backports happened. If there's a JIRA issue, of course you'll get the usual bot comment there. Please "Resolve" JIRA issues yourself; I don't plan to do that for others at this time. If you are manually backporting, please keep the first line the same as this line forms the change's identity within a range of a couple months for my system. Don't mangle it; don't put (9x) or whatever in it. Leave it the same. If committing a fix-up commit directly to main (not via PR process), choose that line wisely, do not use simply "tidy", say. Best practice IMO -- if *any* individual commit relates to a JIRA and/or PR, even a fix-up, then it ought to have subject-line identifiers to make the linkage clear. I hate it when people forget the JIRA reference if one could have been provided. If you do use "tidy" or really anything without a PR reference then backport it yourself; my system will skip it. If you don't use GitHub then a commit won't get backported by my system because I don't know the intended branch target. You are on your own -- do the backporting yourself as usual. Similarly, if you use GitHub but don't set a milestone on a PR, my system won't backport it. If you have already backported it and set the milestone afterwards, my system will see that it has already been handled (due to commit subject line occurrence on target branches). If you used a different subject line, I suspect my system will eventually observe the change has already happened and skip it. I'd like to see the Renovate bot set 10.x milestone on its PRs, but haven't done so. I don't know if it makes sense to bother setting the milestone on any/all PRs *after* it has already been backported. Maybe? We don't use this GitHub feature yet for anything except what I propose here. Of course I'll share the scripts & skills. At present it's a bit early and I'm refining them. Although it's tempting to put them into dev-tools, imagine switching branches during the porting process and suddenly running an older version of the script. Yikes! So I think maybe the Solr sandbox would be a better home. Heck, the same argument could be said for the smoketester, which has annoyed me when iterating on it because it required porting to several branches back when I was working on the 9x release. What a pain. On Wed, Jun 17, 2026 at 1:04 AM David Smiley <[email protected]> wrote: > 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 >
