[llvm-dev] Policy on support tiers

[Eric Christopher via llvm-dev]

+1 :)

-eric

On Fri, Oct 30, 2020 at 5:21 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>
> _______________________________________________
> 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/2c770a33/attachment.html>