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
Item removed
Dmitry MisharovWed 23 Sep 2026 12:46PM
@Tomas Mraz I tried to address your comments in https://github.com/openssl/project/pull/2063/changes/907220d58d95a9a1424dbe4865a30ebed036e790
Richard Levitte (individual)Tue 22 Sep 2026 2:05PM
Re autosquashable commits (fixup! / squash! / amend!), I hope you're aware that they can cause conflicts, since they do infer a rearrangement of the commits.
As a matter of fact, I've started to autosquash and force-push my branches instead, to always keep the set of commits clean. Github's force-pushed link usually show the changes just fine; just don't push a rebase + fixes in one push. (this is, BTW, an expected workflow for someone that uses jj)
Dmitry MisharovWed 23 Sep 2026 12:47PM
@Richard Levitte (individual) Please check the latest version in https://github.com/openssl/project/pull/2063
Richard Levitte (individual)Tue 22 Sep 2026 2:08PM
Also, I see the document assume that everyone use ghmerge. I don't, and would like to know if there are changes when pushing for a merge that I should be aware of.
Uri BlumenthalTue 22 Sep 2026 2:14PM
Yes, this makes sense. I support this proposal.
Todd ShortTue 22 Sep 2026 4:47PM
I don't use ghmerge either, but I do build and test before pushing. So saying that "nothing" ever builds the commits that land is a misnomer. That being said, I know why we have the enterprise GitHub server, but it doesn't feel "open" or up-front. When a PR merges, GitHub indicates that it's been closed, rather than merged, which just seems "weird", and possibly confusing to new contributors.
I would prefer we use GitHub merge processes, but that needs to be weighed against the embargoed CVE fix process.
Richard Levitte (individual)Wed 23 Sep 2026 5:59AM
@toddshort, the github way would be to push to the PR branch after autosquash + addrev, and then rebase and push to the base branch. Github detects that and automatically marks the PR "merged".
I did that a few times in the past, but got some pushback from folks who wanted to continue to see the PRs in its "original" (pre-addrev, pre-autosquash) form. Me, I'm pretty 🤷 on the topic...
Richard Levitte (individual)Wed 23 Sep 2026 6:04AM
That being said, I don't really care about github data as much as I care about git history. In the end, it's the latter that's most durable.
Tomas Mraz ·Tue 22 Sep 2026 1:56PM
A few comments and questions:
So the bot will apply the `addrev` annotations and push to the primary GHE repo if CI is green?
What about the flaky tests? IMO there must be a step where non-green CI is allowed to be manually overridden otherwise this process will not be workable.
Also, I'd say that we do not actually need the automated extra CI run in the PR - we should just do this run on merge. There is no need to duplicate that.
As for the cherry-picks - the PRs for cherry-picks must NOT require reapprovals if the cherry-pick is clean. Otherwise we are putting an extra unnecessary review burden on ourselves. And we cannot cope with the review queue already.
Furthermore there has to be a way to manually fix things if the automation does not get things right.