MR does not merge

[Ben Gamari]

Clinton Mead <clintonmead at gmail.com> writes:

> Hi All
>
> I'm not a GHC dev so my understanding of this process is limited to this
> thread but just my thoughts.
>
> My understanding is that we want to achieve the following two goals:
>
> 1. Never allow code which breaks tests to be committed to master.
> 2. Ensure that master is up to date as soon as possible with recently
> submitted merge requests (MR).
>
> The issue seems to be that the only way to ensure 1 is to use a serial
> "rebase/test/make master branch" process on every MR. Which means if you
> get a lot of MRs in a row you can get a queue of MRs blowing out.
>
> So what I propose is the following:
>
> 1. Keep a queue of pending MRs.
> 2. When the previous test is complete, create a branch (lets call it
> "pending") which is all the MRs in the queue rebased firstly on master and
> then each other. Drop any MRs which fail this rebasing.
> 3. Run tests against "pending"
> 4. If the tests pass, "pending" becomes "master". However, if the CI for
> "pending" fails, "split" pending into two (half the MRs in each, perhaps
> interleaving their size also), rebase them separately on master call them
> "pending1" and "pending2". If there's only one MR pending, don't "split" it
> (you can't), just report the test failure to the MR owner.
> 5. If either "pending1" or "pending2" passes, it becomes "master". Also,
> whether either or both of "pending1" or "pending2" fails, go back to step 4
> for these. If they both pass (which probably should never happen) maybe
> just merge one into master arbitrarily and put the other MRs in the pending
> MR queue.
> 6. Once we've merged all our MRs in to master (and perhaps through the
> binary search above found the broken MR) start this process again with the
> current pending MRs.
>
> With this process we ensure master is never broken, but we can test and
> merge n MRs in log(n) time, so the MR queue will not grow arbitrarily long
> if the rate of submitted MRs exceeds the rate we run CI tests on them.
>
> "Marge-bot" mentioned almost does what I suggest, except in the case of a
> failure it runs the MRs one-by-one, instead of binary split like I suggest.
> Perhaps my proposal could be best implemented as a patch to Marge-bot.
>
What you propose is similar to what upstream is planning [1]. While it
would be nice to have a better solution until this plan comes to
fruition, I'm personally a bit reluctant to put much effort into
marge-bot given that it really is just a stop-gap solution.

Of course, if someone else would like to pick up this project we would
be quite appreciative.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9186
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190121/e1a3eed7/attachment.sig>