GitHub merge queue is generally available

[Jay-o-Way]

Description of the new feature / enhancement

General availability of GitHub’s merge queue means good-bye to traffic jams on your team’s busiest branches. No more rushing to merge your pull requests before someone else merges theirs 🥵. Turn on GitHub’s merge queue today and accelerate your merge velocity 🚀.

Any team that is part of a managed organization with public repositories and GitHub Enterprise Cloud users will be able to enable this feature on their respective repository and start streamlining their team’s pull requests immediately. If this describes you, then let the commit parties commence 🎉.

Scenario when this would be used?

Merge queue is designed for high-performance teams where multiple users regularly commit to a single branch. Prior to merge queue, engineers would need to attempt to merge directly onto an already busy branch—potentially running into code conflicts, and then spiraling into a cycle of rework.

Supporting information

https://github.blog/2023-07-12-github-merge-queue-is-generally-available/

[Jay-o-Way]

@snickler @jaimecbernardo @davidegiacometti @stefansjfw what's your experience and opinion?

[davidegiacometti]

Haven't used merge queue yet.
Wondering if is worth to use considering the volume of PR of this repo.

[snickler]

I agree. It could be worth checking out, especially if we want to make sure certain things get merged in order 🤔 - Jeremy Sinclair

…

________________________________

[stefansjfw]

Opinion: I'd try it out. Might be beneficial
Experience: Haven't tried it
:)

[Jay-o-Way]

Anybody want to try? @crutkas ?

[Jay-o-Way]

Thanks for opening this PR! I'm thinking it makes more sense to get it in only after #28722 and #29023 get in.
I'd like to avoid conflicts on those. WDYT?

#29114 (review)

[Jay-o-Way]

@crutkas the recent prs about updating dependencies seems like a great case to test this. What do you think? What would keep us?