Hacker News Reader

The limitation of Bors for us was throughput, we were more interested in testing multiple simultaneous pull requests merging at the same time, rather than testing against the latest master.

With our CI times and PR volume, by the time any CI run completes, master would have drastically changed.

View on HN

Sequentializing landing so that you can ensure passing tests is the main feature of bors. The normal GitHub CI flow is already what you wanted apparently.

In a bors workflow, bors is the only thing allowed to push to master, so master cannot get out of date.

The Rust projects solves throughput with rollups, which are semi-automated. It would be nice if someone would write fully automated rollup support into a bors, but alas, no one has tried that I know of.

You don't need absolute sequentiality for bors's guarantees. You can speculatively build and try to merge multiple PRs in parallel even though only one will "win". That's fine and not thundering herd stupidity of your build system is incremental so you can share work.

None of this is new at all, btw, I'm just regurgitating MVCC from postgresql.

Reply on news.ycombinator.com