[doc] Clarify responsibility for fixing experimental target problems

Experimental targets are meant to be maintained by the community behind
the target. They are not monitored by the primary build bots. This
change clarifies that it is this communities responsibility for things
like test fixes related to the target caused by changes unrelated to
that target.

See http://lists.llvm.org/pipermail/llvm-dev/2020-February/139115.html
for a full discussion.

Reviewed by: rupprecht, lattner, MaskRay

Differential Revision: https://reviews.llvm.org/D74538

diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index 883556f..e38ce93 100644 (file)
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -570,9 +570,15 @@ and then trying to fix emergent problems in-tree is problematic for a variety
 of reasons.
 
 For these reasons, new targets are *always* added as *experimental* until
-they can be proven stable, and later moved to non-experimental. The difference
-between both classes is that experimental targets are not built by default
-(need to be added to -DLLVM_TARGETS_TO_BUILD at CMake time).
+they can be proven stable, and later moved to non-experimental. The differences
+between both classes are:
+
+* Experimental targets are not built by default (they need to be explicitly
+  enabled at CMake time).
+
+* Test failures, bugs, and build breakages that only appear when the
+  experimental target is enabled, caused by changes unrelated to the target, are
+  the responsibility of the community behind the target to fix.
 
 The basic rules for a back-end to be upstreamed in **experimental** mode are: