Skip to content

Switch to GH merge queue? #3882

@RalfJung

Description

@RalfJung

The idea of switching from bors to GH merge queues has come up multiple times. "Old" bors often has trouble (though in the recent past it worked just fine), and IIRC, t-infra recommends that most smaller projects switch to merge queues rather than "new" bors. This also has the advantage of working around rust-lang/rust#101907 since we'd no longer have bors commits as part of the sync.

The main downside is increased latency: github waits until PR CI passes before even putting the PR in the queue, so one can't just push + r+ immediately, one has to wait for two times the CI time until the PR actually lands. However, landing PRs is rarely latency-sensitive so I don't think this is a big enough problem.

@rust-lang/miri what do you think?

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-testsArea: affects our test suite or CIC-proposalCategory: a proposal for something we might want to do, or maybe not; details still being worked out

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions