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

[Renato Golin via llvm-commits]

rengolin added inline comments.

================
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
----------------
andreybokhanko wrote:
> 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?
The BPF back-end started experimental, then moved to non-experimental.

http://lists.llvm.org/pipermail/llvm-dev/2015-June/086492.html

So, I think making it a requirement is a strong suggestion that we don't want to fast-track targets, since they won't have proven that they can "cope with upstream development pace for the required time".

================
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.
+
----------------
andreybokhanko wrote:
> I don't understand this (most likely my bad) -- how keeping a target downstream helps with openness and quality concerns?
No, that's a horrible paragraph, but I didn't know how to say it better. :)

My point here is that, in the same way the target's community (a company, maybe) may want to keep the targets downstream (secrecy, product roadmap, etc), the LLVM community may also refuse to accept a target upstream just because the company wants to. Ie. this is a two-way street.

For example, when the Lanai back-end was proposed, there were concerns that the lack of documents, emulators and targets available would make it unusable for everyone *but* the Lanai community, so a cost to everyone else for the sake of saving time to the Lanai community.

But later they have shown interest in publishing ISA docs and will make an emulator open source, so that has shown interest, usefulness and also reduces the tension in the LLVM community.

I'd love if someone could convey that idea into a concise and meaningful paragraph. :)

================
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.
+
----------------
andreybokhanko wrote:
> 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.
I agree, it is a bit harsh. Wasn't meant to be. :)

I'll re-word.


Repository:
  rL LLVM

https://reviews.llvm.org/D23162