<div dir="ltr">Hi Luke,<div><br></div><div>I would like to add a thought in another direction. We could reduce some of the pain with two flavors of continuous integration:</div><div><br></div><div>1) We could be running some <b>*automatic integration testing with downstream users*</b>: Have some *<b>public*</b> CI machine build the heads of LLVM and a downstream project (e.g. Rust, Tensorflow) and see if the builds still pass. </div><div><br></div><div>This would make it easier to identify the breakages and provide feedback to a) the person implementing the change and b) the downstream users who might need to adapt to that change. At least a couple of Rust and TensorFlow folks would be interested in that. However that only works for open source usages of LLVM.</div><div><br></div><div>Augie and I set up a *<b>prototype for a LLVM + Rust CI build*</b> [1] to see what that would look like. This would certainly need more discussion and work for production use.</div><div><br></div><div>2) Not really addressing your ABI/API use case: We could try to move towards *<b>100% pre-merge testing*</b> (i.e. building every change before merging it to the main branch). I chased down a couple of "NFCs" that broke the build or some test. That could have been prevented with pre-merge testing. This is not trivial to implement and would require a workflow change.</div><div><br></div><div>This approach would not solve the tagging question, but we could reduce some of the pains around debugging broken builds.<br></div><div><br></div><div>[1] <a href="https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds?branch=master">https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds?branch=master</a></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best,<div>Christian</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 17, 2021 at 7:11 PM Luke Drummond 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:1px solid rgb(204,204,204);padding-left:1ex">Hi all<br>
<br>
Twice in the last week I've had to bisect crashes in the middle end or failed CI<br>
due to commits marked "[NFC]" that changed something fundamental about a public<br>
API or the format of IR.<br>
<br>
While I understand LLVM's always been pretty fluid with API and ABI stability,<br>
it smacks a little when the offending commit is marked "[NFC]".<br>
<br>
Can some elders / code-owners comment on the expected threshold for what no<br>
longer counts as "NFC"? I'd personally like to limit its usage to things like<br>
changing a local variable name, rewording a comment, or clang-formatting<br>
something - not API, ABI, or IR changes.<br>
<br>
All the Best<br>
<br>
Luke<br>
-- <br>
Codeplay Software Ltd.<br>
Company registered in England and Wales, number: 04567874<br>
Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>