<div dir="ltr"><div>I realise that llvm trunk can move fairly quickly. </div><div>So my original, but brief, suggestion was to merge the current set of approved patches together rather than attempting them one at a time.</div><div>Build on a set of fast smoke test bots. If something breaks, it should be possible to bisect it to reject a PR and make forward progress.<br></div><div>Occasionally bisecting a large set of PR's should still be less bot time than attempting to build each of them individually.</div><div>Blocking the PR's due to target specific and or slow bot failures would be a different question.<br></div><div>You could probably do this with a linear history, so long as the final tree is the same as the merge commit, it should still build.<br></div><div>I'm just fond of the idea of trying to prevent bad commits from ever being merged. Since they sometimes waste everyone's time.<br></div><br class="gmail-Apple-interchange-newline"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 04:02, David Greene <<a href="mailto:dag@cray.com">dag@cray.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"><<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> writes:<br>
<br>
> Systems that I've seen will funnel all submitted PRs into a single queue<br>
> which *does* guarantee that the trial builds are against HEAD and there<br>
> are no "later commits" that can screw it up. If the trial build passes,<br>
> the PR goes in and becomes the new HEAD.<br>
<br>
The downside of a system like this is that when changes are going in<br>
rapidly, the queue grows very large and it takes forever to get your<br>
change merged.  PR builds are serialized and if a "build" means "make<br>
sure it builds on all the Buildbots" then it takes a very long time<br>
indeed.<br>
<br>
There are ways to parallelize builds by speculating that PRs will build<br>
cleanly but it gets pretty complicated quickly.<br>
<br>
> But this would be a radical redesign of the LLVM bot system, and would<br>
> have to wait until we're done with the GitHub migration and can spend<br>
> a couple of years debating the use of PRs. :-)<br>
<br>
Heh.  Fully guaranteeing buildability of a branch is not a trivial task<br>
and will take a LOT of thought and discussion.<br>
<br>
                              -David<br>
</blockquote></div></div>