<div dir="ltr"><div>Hi Moritz,</div><div><br></div><div>I, too, had my gripes with CI turnaround times in the past. Here's a somewhat radical proposal:</div><ul><li>Run "full-build" stage builds only on Marge MRs. Then we can assign to Marge much earlier, but probably have to do a bit more of (manual) bisecting of spoiled Marge batches.</li><ul><li>I hope this gets rid of a bit of the friction of small MRs. I recently caught myself wanting to do a bunch of small, independent, but related changes as part of the same MR, simply because it's such a hassle to post them in individual MRs right now and also because it steals so much CI capacity.</li></ul><li>Regular MRs should still have the ability to easily run individual builds of what is now the "full-build" stage, similar to how we can run optional "hackage" builds today. This is probably useful to pin down the reason for a spoiled Marge batch.<br></li><li>The CI capacity we free up can probably be used to run a perf build (such as the fedora release build) on the "build" stage (the one where we currently run stack-hadrian-build and the validate-deb9-hadrian build), in parallel.</li><li>If we decide against the latter, a micro-optimisation could be to cache the build artifacts of the "lint-base" build and continue the build in the 
validate-deb9-hadrian build of the "build" stage.</li></ul><div>The usefulness of this approach depends on how many MRs cause metric changes on different architectures.</div><div><br></div><div>Another frustrating aspect is that if you want to merge an n-sized chain of dependent changes individually, you have to</div><div><ul><li>Open an MR for each change (initially the last change will be comprised of n commits)<br></li><li>Review first change, turn pipeline green   (A)<br></li><li>Assign to Marge, wait for batch to be merged   (B)</li><li>Review second change, turn pipeline green</li><li>Assign to Marge, wait for batch to be merged</li><li>... and so on ...<br></li></ul><div>Note that (A) incurs many context switches for the dev and the latency of *at least* one run of CI.</div><div>And then (B) incurs the latency of *at least* one full-build, if you're lucky and the batch succeeds. I've recently seen batches that were resubmitted by Marge at least 5 times due to spurious CI failures and timeouts. I think this is a huge factor for latency.</div></div><div><br></div><div>Although after (A), I should just pop the the patch off my mental stack, that isn't particularly true, because Marge keeps on reminding me when a stack fails or succeeds, both of which require at least some attention from me: Failed 2 times => Make sure it was spurious, Succeeds => Rebase next change.</div><div><br></div><div>Maybe we can also learn from other projects like Rust, GCC or clang, which I haven't had a look at yet.</div><div><br></div><div>Cheers,</div><div>Sebastian<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 17. Feb. 2021 um 09:11 Uhr schrieb Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Friends,<br><div><br>I've been looking at CI recently again, as I was facing CI turnaround times of 9-12hs; and this just keeps dragging out and making progress hard.</div><div><br></div><div>The pending pipeline currently has 2 darwin, and 15 windows builds waiting. Windows builds on average take ~220minutes. We have five builders, so we can expect this queue to be done in ~660 minutes assuming perfect scheduling and good performance. That is 11hs! The next windows build can be started in 11hs. Please check my math and tell me I'm wrong!</div><div><br></div><div>If you submit a MR today, with some luck, you'll be able to know if it will be mergeable some time tomorrow. At which point you can assign it to marge, and marge, if you are lucky and the set of patches she tries to merge together is mergeable, will merge you work into master probably some time on Friday. If a job fails, well you have to start over again.</div><div><br></div><div>What are our options here? Ben has been pretty clear about not wanting a broken commit for windows to end up in the tree, and I'm there with him.</div><div><br></div><div>Cheers,</div><div> Moritz</div></div>
_______________________________________________<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>