[llvm] 3073cbd - [docs] link new support policy from developer policy

[Renato Golin via llvm-commits]

Author: Renato Golin
Date: 2020-11-10T19:40:57Z
New Revision: 3073cbd2d4c26f8c17c827524c9b7b73fcb2dce7

URL: https://github.com/llvm/llvm-project/commit/3073cbd2d4c26f8c17c827524c9b7b73fcb2dce7
DIFF: https://github.com/llvm/llvm-project/commit/3073cbd2d4c26f8c17c827524c9b7b73fcb2dce7.diff

LOG: [docs] link new support policy from developer policy

Adding new paragraphs under "Introducing New Components" section to
check the different levels of support we have, to help introduction of
smaller set of changes without overwhelming new collaborators and
potentially losing the contribution.

Differential Revision: D91013

Added: 
    

Modified: 
    llvm/docs/DeveloperPolicy.rst

Removed: 
    


################################################################################
diff  --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index 7db365e0bb5f..3fa629965318 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -569,8 +569,12 @@ collaboration across industry and academia.
 
 That said, we need to strike a balance between being inclusive of new ideas and
 people and the cost of ongoing maintenance that new code requires.  As such, we
-have the following general policies for introducing major new components into
-the LLVM world.  However, this is really only intended to cover common cases
+have a general :doc:`support policy<SupportPolicy>` for introducing major new
+components into the LLVM world, depending on the degree of detail and
+responsibility required. *Core* projects need a higher degree of scrutiny
+than *peripheral* projects, and the latter may have additional 
diff erences.
+
+However, this is really only intended to cover common cases
 that we have seen arise: 
diff erent situations are 
diff erent, and we are open
 to discussing unusual cases as well - just start an RFC thread on the
 `llvm-dev mailing list`_.
@@ -580,13 +584,16 @@ Adding a New Target
 
 LLVM is very receptive to new targets, even experimental ones, but a number of
 problems can appear when adding new large portions of code, and back-ends are
-normally added in bulk.  We have found that landing large pieces of new code
-and then trying to fix emergent problems in-tree is problematic for a variety
-of reasons.
+normally added in bulk. New targets need the same level of support as other
+*core* parts of the compiler, so they are covered in the *core tier* of our
+:doc:`support policy<SupportPolicy>`.
+
+We have found that landing large pieces of new code 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.
 
-For these reasons, new targets are *always* added as *experimental* until
-they can be proven stable, and later moved to non-experimental. The 
diff erences
-between both classes are:
+The 
diff erences between both classes are:
 
 * Experimental targets are not built by default (they need to be explicitly
   enabled at CMake time).
@@ -670,10 +677,11 @@ in general <https://en.wikipedia.org/wiki/Monorepo>`_ are great because they
 allow atomic commits to the project, simplify CI, and make it easier for
 subcommunities to collaborate.
 
-That said, the burden to add things to the LLVM monorepo needs to be very high -
-code that is added to this repository is checked out by everyone in the
-community.  As such, we hold subprojects to a high bar similar to "official
-targets", they:
+Like new targets, most projects already in the monorepo are considered to be in
+the *core tier* of our :doc:`support policy<SupportPolicy>`. The burden to add
+things to the LLVM monorepo needs to be very high - code that is added to this
+repository is checked out by everyone in the community.  As such, we hold
+components to a high bar similar to "official targets", they:
 
  * Must be generally aligned with the mission of the LLVM project to advance
    compilers, languages, tools, runtimes, etc.