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

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 2 12:37:27 PST 2020


Hi,

Nice proposal Renato! I'm very supportive of the direction in general.

I share the sentiment of Eric and Geoffrey in general though.
In particular, it wasn't clear to me that something like flang for example
would be tier 2, I told the flang maintainer to feel free to revert my
patches when I break their bot for example. I assumed that every subproject
in the monorepo was supported as long as they have public bots. The only
explicit unsupported things are the experimental LLVM backends I believe?

Thanks for iterating on this! :)

Cheers,

-- 
Mehdi

On Mon, Nov 2, 2020 at 12:33 PM Eric Christopher via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>>
>> _______________________________________________
> 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/20201102/30a65f9d/attachment.html>


More information about the llvm-dev mailing list