[llvm-dev] Policy on support tiers

[Jacques Pienaar via llvm-dev]

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