[llvm-dev] Policy on support tiers

[Keane, Erich via llvm-dev]

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<mailto:jpienaar at google.com>> wrote:
+Geoffrey Martin-Noble<mailto:gcmn at google.com>

On Fri, Oct 30, 2020 at 8:45 AM Renato Golin via llvm-dev <llvm-dev at lists.llvm.org<mailto: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<mailto: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/a193d202/attachment.html>