[llvm-dev] Policy on support tiers, take 2
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 3 09:25:54 PST 2020
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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/20201103/6e36cc30/attachment.html>
More information about the llvm-dev
mailing list