[llvm-dev] "[NFC]" Abuse

Michael Kruse via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 22 07:17:37 PDT 2021


Am Di., 22. Juni 2021 um 04:52 Uhr schrieb Christian K├╝hnel via
llvm-dev <llvm-dev at lists.llvm.org>:
> I would like to add a thought in another direction. We could reduce some of the pain with two flavors of continuous integration:
>
> 1) We could be running some *automatic integration testing with downstream users*: Have some *public* CI machine build the heads of LLVM and a downstream project (e.g. Rust, Tensorflow) and see if the builds still pass.
>
> 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.

I am against such thing for the following reasons:
 - LLVM developers cannot see whether their commit or a downstream
commit caused a failure.
 - It gives those selected projects privileged access to the LLVM
development direction. Suddenly downstream problems become blockers
(e.g. downstream code has undefined behaviour and we cannot improve
the optimizer until downstream is fixed).
 - It is also unnecessary. We already have the llvm-test-suite.
Downstream projects can add their code here as well.

Downstream CI maintainers can already report problems that they
identified to be caused by Clang to the LLVM project, like the
Chromium and Fuchsia teams do and their CI runs are also accessible
via public webpages
(https://ci.chromium.org/p/chromium/g/chromium.clang/console).
However, the burden of identifying the problem is theirs.

Michael


More information about the llvm-dev mailing list