Current merge rules are too inconvenient

[LogicParrot]

Currently, a single accepted merge blocks out all other PRs until their owners either rebase or merge "master" into their branch. This slows things down a lot. e.g. this


I think fixing this is extra urgent. It's significantly bottlenecking merges and a queue is building up.

This is making simple operations really hard. For instance, @Gargaj has 5 open PRs. He'll have to keep rebasing them after each merge in order for me to merge his next PR. That's at least 5 rebases.

[bearbin]

Yes. This got disabled a while ago, how come it got re-enabled?

[worktycho]

Because we need to require status checks. Protected branches shouldn't be blocking merges from my understanding of githubs docs.

---

Looking closer, it looks like if you enable required status checks, it blocks if the branch is not up to date with master. So you can't have the required status checks feature, and the ability to merge out of date PR's.

[LogicParrot]

Because we need to require status checks.

Can't we just ask people not to commit directly into `master` and not to merge before CI finishes? Do "status checks" provide any other features we use?

[worktycho]

The don't force push master setting is separate, so we can keep that.

---

I'm going to try disabling this for a couple of weeks, and see what happens.

[xoft]

We've had some trigger-happy people who would merge even before the CI completed, let alone some review from the others. I hope those are now educated enough

[LogicParrot]

1. Blocking merges whose CI did not succeed / has not finished
2. Blocking merges whenever master is ahead of them by one or more commits

These sound like two seperate options to me. Are they interwined in Github for some reason?