[PATCH] D23162: [docs] Adding target status definition to dev policy

[Andrey Bokhanko via llvm-commits]

andreybokhanko added a comment.

Hi Renato,

Thank you for working on this!

My comments (purely subjective ones, really, not hard objections at all) are below.

Yours,
Andrey


================
Comment at: docs/DeveloperPolicy.rst:565
@@ +564,3 @@
+
+For these reasons, new targets are *always* added as *experimental* until
+they can be proven stable, and then moved to non-experimental. The difference
----------------
Should we stress *always*? In the discussion you present an example of a target (BPF) that was added as an official right away (http://lists.llvm.org/pipermail/llvm-dev/2016-July/102505.html). Maybe it's better to say *practically always* or something like this?

================
Comment at: docs/DeveloperPolicy.rst:572-573
@@ +571,4 @@
+upstream. Secrecy is a reason for companies to keep them downstream, but
+openness and quality concerns are reasons for the *community* to prefer that it
+remains downstream, too.
+
----------------
I don't understand this (most likely my bad) -- how keeping a target downstream helps with openness and quality concerns?

================
Comment at: docs/DeveloperPolicy.rst:625-628
@@ +624,6 @@
+
+* The maintainer(s) must continue following these rules throughout the lifetime
+  of the target. Violations of the policy will be treated on a case by case
+  basis, but several and continuous violations could be met with complete
+  removal of the target from the code base.
+
----------------
I'm not entirely happy with the wording, which makes target maintenance look like a daily walk through a minefield, with each single mistake evaluated and penalties taken. I guess your idea is that adhering to the rules and policies shouldn't be forgotten once a target becomes experimental / official. IMHO, just saying that "continuous violations of aforementioned rules and policies could lead to complete removal of the target from the code base" would be sufficient.


Repository:
  rL LLVM

https://reviews.llvm.org/D23162