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

Wed Nov 4 05:45:10 PST 2020

Thanks Philip!

First draft at: https://reviews.llvm.org/D90761

Feel free to copy more people.

cheers,
--renato

On Tue, 3 Nov 2020 at 17:25, Philip Reames <listmail at philipreames.com>
wrote:

> Just want to chime in with support.  I like the general direction and
> agree with the suggest tweaks mentioned so far in this thread.
>
> Philip
> On 11/2/2020 3:56 PM, Eric Christopher via llvm-dev wrote:
>
> 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
>>>
>>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20201104/151de138/attachment.html>