[llvm-dev] Policy on support tiers, take 2

[Renato Golin via llvm-dev]

Ok, so after some feedback, here's an updated version. Separate thread as
the previous got split.

People seem to agree on the overall terms, but there was confusion on the
difference between tier 2 and 3 as well as clarification on what projects
go where.

I have joined tiers 2 and 3 and made explicit the three criteria they fit
into, with the requirements more formally explained.

Please review the sub-project lists on the two tiers, I'm not so sure about
them.

Once we're happy with the "what", I'll send a review for a new doc so we
can discuss the writing and format there (ignore it for now).

Here it goes:

*** Tier 1: the core compiler, officially supported by the community.

Rationale:
 * Common code that supports most projects, upstream and downstream forks
and forms the toolchain itself.
 * Includes everything we release on all architectures and OSs we have
releases on.

What:
 * LLVM itself, clang/tools, compiler-rt, libcxx/abi/unwind, lld, lldb,
openmp, mlir.
 * Basically everything inside the mono-repo that is not in tier 2.
 * Builds on all first class citizen combinations of targets x OSs (incl.
test-suite).
 * The CMake build infrastructure and release scripts.
 * Phabricator & Buildbot infrastructure.
 * The test-suite repository.

Requirements:
 * Follow all core development policies on code quality, reviews, reverts,
etc.
 * Noisy green buildbots, emailing all developers.
 * Most not be broken by changes in tier 2 (ex. if they require tier 1
changes).
 * Bitrot will downgrade areas to tier 2 or be removed, depending if a
sub-community picks up support and has a timeline to fix.

*** Tier 2: side projects that integrate with the compiler and that
*should* work at all times.

Rationale:
 * Code that is making its way into LLVM core (tier 1) via
experimental/incubator roadmaps, or;
 * Code that isn't meant to be in LLVM core, but has a sub-community that
maintains it long term, or;
 * Code that is making its way out of LLVM core (legacy) and that is a
strong candidate for removal.

What:
 * Experimental targets/options.
 * Experimental mono-repo projects (flang, libc, libclc, parallel-libs,
polly, beduginfo-tests?, pstl?)
 * Incubator projects (circt, mlir-npcomp, etc).
 * Legacy tools (lnt).
 * Alternative build systems (gn, bazel).
 * Tool support (gdb scripts, editor configuration, helper scripts).

Requirements:
 * Follow all core development policies on code quality, reviews, reverts,
etc.
 * Infrastructure that only notify its sub-community.
 * Most not break tier 1, promptly reverting if it does, with discussions
to be done offline before reapply.
 * Leaner policy on bots being red for longer, as long as the sub-community
has a roadmap to fix.
 * Leaner policy on bitrot, as long as it doesn't impact tier 1 or other
tier 2 projects.
 * Should be easy to remove (either separate path, or clear impact in code).
 * Must have a document making clear status, level of support and, if
applicable, roadmap into tier 1 / out of LLVM.


cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201102/36365f42/attachment.html>