[llvm-dev] Policy on support tiers

Fri Oct 30 14:20:38 PDT 2020

I personally see a difference between "subprojects" (like lld, clang,
flang, circt ...) which are conceptually either independent from LLVM or
built on top from a layering point of view ; and on the other hand things
like the IDE, debugger, build scripts which are about LLVM itself and
intended to serve users of LLVM.
The incubator process as I understand it has been introduced to address the
former more than the latter.

On Fri, Oct 30, 2020 at 12:33 PM Keane, Erich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> So, I thought that the whole idea of the ‘incubator’ was to take up tiers
> 2/3 until they were sufficiently baked for tier 1.  Is this intended to go
> against that for some things (that is, Bazel in this case)?
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Geoffrey
> Martin-Noble via llvm-dev
> *Sent:* Friday, October 30, 2020 11:57 AM
> *To:* Jacques Pienaar <jpienaar at google.com>
> *Cc:* LLVM Dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Policy on support tiers
>
>
>
> On Fri, Oct 30, 2020 at 11:36 AM Jacques Pienaar <jpienaar at google.com>
> wrote:
>
> +Geoffrey Martin-Noble <gcmn at google.com>
>
>
>
> On Fri, Oct 30, 2020 at 8:45 AM Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
>
>
> It seems the BAZEL[1] discussion is going round in circles and many have
> suggested we encode the policy on the tiers of support we want from the
> community.
>
>
>
> This is not what I think is the best, just what I have interpreted the
> "consensus" seems to think is the best. I may be completely wrong, please
> don't assume anything other than a faulty attempt at getting it right.
>
>
>
> I tried to use different words like "must", "should", "could", "will",
> etc. to convey the right meaning, but I'm not a native English speaker, so
> feel free to tweak that to get the right balance.
>
>
>
> Here it goes.
>
>
>
> *** Tier 1: the core compiler, which *must* work at all times.
>
>   * Front-ends, back-ends, middle-ends, libraries, core APIs, official
> projects and tools.
>
>   * The CMake build infrastructure.
>
>   * Builds on all first class citizen combinations of targets x OSs. [2]
>
>   * Vim support (kidding!! :)
>
>
>
> It must:
>
>   * have noisy green bots
>
>   * revert on failure policy
>
>   * etc?
>
>
>
> *** Tier 2: side projects that integrate with the compiler and that
> *should* work at all times.
>
>   * Experimental targets, infrastructure and APIs, non-default cmd-line
> options
>
>   * Alternative build systems (ex. GN, Bazel)
>
>
>
> It must not:
>
>   * Break or hinder tier 1
>
>   * Increase validation noise beyond its scope
>
>
>
> It should:
>
>   * Have green buildbots, handled by the sub-community that cares about it
>
>   * Have notifications only to those interested when things break (avoid
> bitrot)
>
>
>
> Sub-communities that care about it *must* fix issues in them, but the rest
> of the community has no obligations to support it. Lack of maintenance
> *could* be subject to removal.
>
>
>
> *** Tier 3: miscellaneous accessories
>
>   * Helper scripts, editor files, debugger scripts, etc.
>
>   * Whatever is detached enough that bit rot is irrelevant
>
>
>
> I think bit rot is never really totally "irrelevant". Perhaps "detached
> and small enough that bit rot is a minor concern"?
>
> It must not:
>
>   * Break or hinder tiers 1 or 2
>
>   * Increase validation noise beyond its scope
>
>
>
> It should:
>
>   * Have a sub-community that cares about it and maintain it
>
>
>
> Sub-communities that care about it *should* fix issues in them, but the
> rest of the community has no obligations to support it. Lack of maintenance
> *will* be subject to removal.
>
>
>
> cheers,
>
> --renato
>
>
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-October/146138.html
>
> [2] Existing definition of "first-class", could be updated / moved here.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> Thanks for kicking this off Renato. This looks very similar to what I
> would've written after that discussion except that I'm not sure I see the
> clear distinction between when something should be considered tier 2 vs 3.
> It seems like if something is sufficiently big it's not *allowed* to be
> tier 3 and must have a buildbot and remain green? And tier 2 seems to be
> largely an extension of the "experimental targets" policy, but encompassing
> things that aren't targets.
>
>
>
> Some additional constraints I would add:
>
> 1. Something in a higher tier may never depend on something in a lower
> tier.
>
> 2. Items in tiers <1 must always be simple to remove (`rm -rf
> /path/to/thing` ideally, although experimental backends also include some
> CMake options).
>
> 3. Items in tiers <1 must have clear documentation accompanying them
> indicating their less-supported status.
> _______________________________________________
> 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/20201030/35644fdd/attachment.html>