[llvm-dev] Policy on support tiers

[Renato Golin via llvm-dev]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/da5d1107/attachment.html>