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

Mon Nov 2 15:56:01 PST 2020

Sounds good, thanks! :)

-eric

On Mon, Nov 2, 2020 at 6:49 PM Renato Golin <rengolin at gmail.com> wrote:

> Right, that's a good split, I think. Only monorepo, minus experimental,
> unsupported build systems and helper files.
>
> I'll send another update tomorrow morning.
>
> Thanks everyone!
>
> On Mon, 2 Nov 2020, 20:38 Mehdi AMINI via llvm-dev, <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>>
>> _______________________________________________
>> 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/0c14b31c/attachment-0001.html>