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

Mon Nov 2 15:49:15 PST 2020

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/62d06c53/attachment.html>