Skip to content

Instantly share code, notes, and snippets.

@richardstephens

richardstephens/multibors notes.md

Last active October 25, 2020 14:51
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save richardstephens/2fd16a0ec224531b890a1be20789d5ca to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save richardstephens/2fd16a0ec224531b890a1be20789d5ca to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. richardstephens revised this gist Oct 25, 2020. 2 changed files with 46 additions and 20 deletions.
    20 changes: 0 additions & 20 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -1,20 +0,0 @@

    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

    46 changes: 46 additions & 0 deletions multibors notes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,46 @@

    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.

    =======

    Decision log
    ------------

    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.

    =======
    Unsolved questions:
    -------------------

    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?
  2. richardstephens created this gist Oct 25, 2020.
    20 changes: 20 additions & 0 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,20 @@

    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