<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 19, 2020 at 1:56 AM David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 18/11/2020 17:36, Mike Edwards via llvm-dev wrote:<br>
> Hi Keith,<br>
> You should be able to access the notes here: <br>
> <a href="https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing</a> <br>
> <<a href="https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing</a>><br>
> Let me know if you run into any issues.<br>
<br>
Thanks.  There's one issue that isn't directly relevant to PRs, but is <br>
likely to become more visible if we go to a PR workflow:<br>
<br>
LLVM takes quite a long time to run the tests and there's usually one <br>
commit in between running the test suite on a patch and pushing it to <br>
master.  If the result then causes test failures, you won't find out <br>
until some time later.  This means I'm generally only willing to hit the <br>
merge button near to the start of the day, when I'm likely to be around <br>
and paying attention when the failure notices come in, which increases <br>
the likelihood that there will be an intermediate patch that causes <br>
problems.<br>
<br>
With a PR-based workflow, it becomes fairly easy to set up a system to <br>
manage a queue of patches to be merged, triggered by either a comment <br>
from a member of the project or a label (e.g. ready-to-merge) being <br>
added to the PR.  The CI infrastructure then rebases the PR on the PR <br>
that's ahead of it in the queue (master if it's the front of the queue), <br>
kicks off the build, and fast-forwards master when it succeeds.  Head is <br>
always in a state where the build bots are happy and if an intermediate <br>
change causes problems then that's reflected in the PR that would see <br>
the failure, nowhere else.  Subsequent PRs in the queue can rebased on <br>
the last passing version and the merge process can continue without a <br>
human needing to notice the buildbot failures and revert anything.</blockquote><div><br></div><div>Such a system is definitely possible, but I wouldn't consider it "fairly easy". Do you have examples of OSS infra to achieve this?</div><div>I also don't believe such a system is a guarantee of "always green master branch":</div><div>1) you have flaky test</div><div>2) it is unlikely that your pre-merge testing can cover the entire matrix of configurations supported by the project: all configs (assert/no assert, build with shared libraries, etc.) time all sanitizers times all subprojects times all host and target platforms?.</div><div><br></div><div>(also implementing such a system from scratch does not really seem harder conceptually with Phabricator patches vs GitHub PR: fundamentally if a phabricator patch can't be applies on top of current HEAD, then the PR couldn't be rebased without conflict either for example, ultimately after `arc patch` you are manipulating the same git branches locally in your CI).</div><div><br></div><div>Thanks,</div><div><br></div><div>-- </div><div>Mehdi</div></div></div>