You can view merged PRs (by *you*) that lack a milestone: https://github.com/apache/solr/pulls?q=is%3Apr+is%3Amerged+merged-by%3A%40me+no%3Amilestone
I have bookmarked this and visit regularly now. On Fri, Jul 10, 2026 at 10:22 PM David Smiley <[email protected]> wrote: > 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 >> >
