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

[Christian Kühnel via llvm-dev]

Hi Renato,

Thank you for working on this! When looking at the topic from the pre-merge
testing perspective 2 questions came to my mind:

1) How should pre-merge testing behave differently on tier 1 vs. 2
projects?
Do we want the builds/tests to pass on broken tier 2 projects?

2) How can we automatically detect the tiers of the projects in the
pre-merge build scripts? If we want to treat them differently we somehow
need to be able to distinguish these in the repo.

Best,
Christian


On Mon, Nov 2, 2020 at 8:58 PM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201103/d2a27855/attachment.html>