...

A separate class of problem exists where an author makes a small innocuous change after a PR has been tested and approved. Technically, any change should be fully retested, but there have been circumstances when this has been skipped (intentionally or otherwise).

A solution to both of problems is to require PRs to be up-to-date before merging (a configuration option in GitHub). However, since our test suite runs for around 2 hours, this would lead to a never-ending cycle of testing and updating from the base branch.

Merge Queue

Rather than chasing down problems in our mainline branches after the fact, or requiring up-to-date PRs in GitHub, this KIP proposes to leverage the Merge Queue feature of GitHub.

...

Following this rollout, we can experiment with the merge group batch size and concurrency. Eventually, we may opt to run some or all tests as part of the merge queue. That remains out of scope of this KIP.

Rejected Alternatives

There aren't really any alternatives to using the merge queue. The current scheme is working fairly well, but has the shortcomings mentioned above. Enabling "require The only other solution to the problems listed above is to require PRs to be up-to-date before merging (a configuration option in GitHub). However, since our test suite runs for around 2 hours, this would lead to a never-ending cycle of testing and updating from the base branch. Enabling the up-to-date " requirement for PRs would be a huge burden on contributors and our CI infra, so it is not really worth consideringinfrastructure.