<div dir="ltr">Hi All<div><br></div><div>I'm not a GHC dev so my understanding of this process is limited to this thread but just my thoughts.</div><div><br></div><div>My understanding is that we want to achieve the following two goals:</div><div><br></div><div>1. Never allow code which breaks tests to be committed to master.</div><div>2. Ensure that master is up to date as soon as possible with recently submitted merge requests (MR).</div><div><br></div><div>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.</div><div><br></div><div>So what I propose is the following:</div><div><br></div><div>1. Keep a queue of pending MRs.</div><div>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.</div><div>3. Run tests against "pending"</div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>"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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 19, 2019 at 2:42 AM Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> writes:<br>
<br>
> |  Indeed this is a known issue that I have been working [1] with upstream<br>
> |  to resolve.<br>
><br>
> Thanks. I'm not equipped to express a well-informed opinion about what<br>
> the best thing to do is. But in the meantime I WOULD be grateful for<br>
> explicit workflow advice. Specifically:<br>
><br>
> * What steps should I take to get a patch committed to master,<br>
>   assuming I've done the review stuff and want to press "go"?<br>
><br>
At the moment it's largely just a matter of when a bulk merge happens; I<br>
did a large merge on Wednesday and another yesterday. <br>
<br>
However, as Matthew suggested I think it may make sense to try using<br>
Marge bot to eliminate this manual process with little cost. It doesn't<br>
take particularly long to put together a bulk merge but it does require<br>
some form of human intervention which generally implies latency.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>