[llvm-dev] Policy on support tiers

[Geoffrey Martin-Noble via llvm-dev]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/6532eaa2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3992 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/6532eaa2/attachment.bin>