Proposal: a merge queue for openssl repository
Dmitry Misharov Tue 22 Sep 2026 1:01PMPublicSeen by 34Nothing ever builds the commit we actually land. ghmerge rebases a PR onto current master on the committer's laptop and pushes it. The PR's CI tested a different commit, against a master that may be days old.
I propose a bot does that rebase, CI runs on the result, and master moves only if it is green. One PR at a time. A failing PR leaves the queue with a comment; master never sees it.
Worth knowing:
- Not a new CI step. At two approvals the bot already runs eleven heavy workflows. The queue runs the same set against the rebased commit and makes it binding.
- Backports become real PRs. Three quarters of release-branch commits today were cherry-picked by hand and never reviewed against that branch. The bot would open the PR.
- Review rules do not change. Two approvals, 24-hour wait, emergency path: all as they are.
- Cost: about 13% more CI. It does not fix flaky tests.
I propose to run a 4 to 6 week shadow pilot: the queue builds and tests the rebased commit and reports, while everyone merges exactly as today. Nothing lands automatically. We would then have real numbers instead of my estimates.
Full document attached. A note on venue: we have no place for proposals like this. Library designs go to `doc/designs`, policies to the policy repos, infrastructure and process proposals nowhere. Separate thread about that.
UPDATE: I created a PR to discuss this here https://github.com/openssl/project/pull/2063
Richard Levitte (individual)Wed 23 Sep 2026 10:45AM
@tomas, they get dismissed, but are still visible. But yeah ok...
Tomas MrazWed 23 Sep 2026 7:02AM
@Todd Short I do not think using GitHub merge process is something we can adopt unless we give up on having the primary repository in the GitHub Enterprise instance. Furthermore there needs to be the commit annotation process which means that you could NOT use the GitHub merge buttons anyway. And losing the commit annotations on merge is something I am very strongly against.
Todd ShortWed 23 Sep 2026 2:57PM
@Tomas Mraz There are ways to maintain a linear history and have the PR merged with the PR number in the headline. It would then be an "extra lookup" to see who actually approved. So, there is no information lost, it's just not in the commit description proper. It would be interesting if there was a way to have those annotations automatically added when github merges the PR.
Todd ShortWed 23 Sep 2026 2:59PM
@Tomas Mraz Just because I have a preference, doesn't mean that anyone else has to have the same preference.
Tomas MrazWed 23 Sep 2026 3:44PM
@Todd Short Depending on GitHub to retrieve such information as the reviewers of a commit is really something we do not want to do. This needs to be stored in git history itself.
Paul DaleTue 22 Sep 2026 9:27PM
By default ghmerge does do a build before it will let you push. You need to pass the --nobuild command line option to suppress this. This isn't a full CI run, but it does catch egregious problems.
On the other hand, pick-to-branch doesn't do a build, so the issue is real here. It does add the cherry picked from lines at least. I didn't know about ghmerge --cherry-pick before today but it seems like it's less useful although easier.
Tomas MrazWed 23 Sep 2026 3:45PM
BTW, please let's move further discussion to https://github.com/openssl/project/pull/2063
Tomas Mraz ·Wed 23 Sep 2026 7:00AM
@Richard Levitte (individual) The biggest problem with pushing rebase + autosquash + addrev to the PR being merged is that the PR approvals get lost this way.