> On Oct 28, 2026, at 11:07 PM, Nicholas Chammas <[email protected]> > wrote: > > I haven’t thought this through fully, but I feel like we should explore the > idea of a custom merge queue > <https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue>. > We mark a PR as ready to merge, and an automated process tests it against > the latest master (using the fork’s GHA budget) and merges it in > automatically on success. If a PR fails the build, it gets removed from the > queue.
Just to clarify why this might help: If we have a queue, then we have a guarantee that every PR is tested against the latest master before it's merged. So there’s no need to do a post-merge build, since we already tested exactly that state right before merging the PR. This is a bit different from what happens today, which is that PRs are tested against the latest master as of the time the PR was last updated. The merge queue addresses that gap. Nick
