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

[Eric Christopher via llvm-dev]

I think I'd work at a little higher level on the things. Explicit lists are
hard to maintain and, in general, I think we're looking at guidelines
rather than hard lists.

-eric

On Mon, Nov 2, 2020 at 3:27 PM Geoffrey Martin-Noble <gcmn at google.com>
wrote:

> I'm not super familiar with all the various subprojects, but I'd be a
> little hesitant to put e.g. libc and flang in the same category as vim
> bindings or the gn build :-D I think I've had failing pre-merge checks from
> both flang and polly before, so at least in practice they don't seem to be
> following the guidelines you mention here. I don't know whether this means
> that they should just be moved up to tier 1, or whether they are actually
> less-supported than some of the more established projects. If their current
> behavior should change, then that seems like a bigger discussion.
>
> I also think it might be better to make this focus specifically on the
> monorepo. Incubator projects already have a clear policy and a lot of the
> fine points here only make sense in the context of the monorepo. e.g. bots
> with blamelists targeting only a subcommunity doesn't make much sense for a
> separate repo. If you committed the the mlir-npcomp repo I think you should
> get notified if you broke something :-D
>
> Apologies if the below falls into the category of "writing", but here are
> some additional thoughts:
>
> I also think that the distinction we previously had with tier 2 vs tier 3
> was useful in terms of differentiating things that need quite a bit of
> promised support to be allowed in the monorepo because they're bigger, more
> complicated, and require constant maintenance (e.g build systems) vs things
> that can be checked in without much discussion because they are small,
> simple, and degrade gracefully (e.g. editor bindings). Maybe separate tiers
> isn't the right way to do that, but I think we should make that distinction
> clear. Like if someone wants to check in bindings for their editor of
> choice, a simple patch seems appropriate, whereas if someone
> (hypothetically ;-P) wants to propose a secondary build system it should at
> least be discussed on the mailing list. Maybe we can just include language
> in the description of tier 2, like:
>
> When adding components intending for tier 2 status, the level of
> discussion and support commitment required is proportional to the size and
> complexity of the component. For example:
> 1. editor bindings can be just be added as a patch following the normal
> review process
> 2. more complex components like a secondary build system should start as
> an RFC that details how this component will be supported
> 3. Experimental backends have an entire section on their introduction
> (link)
>
> On Mon, Nov 2, 2020 at 11:58 AM Renato Golin <rengolin at gmail.com> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201102/21af9750/attachment.html>