-
Notifications
You must be signed in to change notification settings - Fork 394
Closed
Labels
A-testsArea: affects our test suite or CIArea: affects our test suite or CIC-proposalCategory: a proposal for something we might want to do, or maybe not; details still being worked outCategory: a proposal for something we might want to do, or maybe not; details still being worked out
Description
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
Labels
A-testsArea: affects our test suite or CIArea: affects our test suite or CIC-proposalCategory: a proposal for something we might want to do, or maybe not; details still being worked outCategory: a proposal for something we might want to do, or maybe not; details still being worked out