I'm starting work on a fork of bors-ng that i'm calling multibors for now. The goal is to support building multiple staging branches at once. If an r+ comes in while nothign is building, we'll build it as normal. If one or more batches are already building, we'll go through all the currently building batches, and create a new batch with the new PR on top. We'll also create a batch with just the newly R+'ed PR.
Then, when a build completes successfully, we'll check if it can be merged without blocking any of the as-yet-incomplete builds that were started afterwards. If not, we'll put the batch into a pending-merge state. If so, we'll advance master and check if there are any other builds in the pending-merge state that can now also be merged.
This is a high level outline of the strategy. There
This document is a collection of thoughts, notes, unsolved questions, The WIP (still very early, probably don't try to run it yet) is at https://github.com/richardstephens/bors-ng/tree/multi-bors
Long term, it's unclear if this should be an entirely separate fork of bors, or if it should be merged upstream. Once I have things working and tested a bit better, I'll write up an RFC and share it on the bors forum.
=======
Multibors will need to keep track of all the PRs that are in a batch that were not on master when the batch was created, even though the head commit on the staging branch for that batch will only be merging one commit. We will continue to use the link_patch_batch table for this purpose. We will also need to know which PR triggerred the creation of a batch so we can work out ordering. For now, we will solve this by making the order of PRs in the link_patch_batch table significant - i.e. the highest ID will be the PR that triggered the creation of this batch.
What is the purpose of the staging.tmp branch?
- Is it just to check that the branch can be merged without conflicts or is there another purpose?