[llvm-dev] Policy on support tiers

[Chris Tetreault via llvm-dev]

   Thanks for taking this initiative Renato! While this doesn’t completely alleviate my concerns with the addition of the Bazel build system, I think this proposal is valuable in and of itself. It’s worthwhile to have documented policies so that community members who are not in the in-group can point to a violation and state that it’s wrong without needing to have an excess level of clout or coalition to lend their words weight. I’ve suggested a few changes inline below, but I think this is largely reasonable.

  I think talk of committing the Bazel build system to the repo should be tabled until we can ratify this policy, and then it should be re-proposed in terms of how it fits in with this policy. If Bazel is accepted into the repository in conformance with an existing policy that can be enforced, my misgivings would be lessened.

Thanks,
   Christopher Tetreault

> *** 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]

> 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)

I would suggest: that it *must* have a subcommunity that cares about it

> 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.

I would suggest: that lack of maintenance *will* be cause for removal. Perhaps a timetable should be stated? (“if it’s red for more than 1 month, it is subject to removal?”)

> *** Tier 3: miscellaneous accessories
>  * Helper scripts, editor files, debugger scripts, etc.
>  * Whatever is detached enough that bit rot is irrelevant

It sounds to me like the basic difference between tier 2 and 3 is that tier 2 needs to have a (quiet) build bot, and tier 3 does not need a build bot? If so, we should state the requirement for a public build bot under tier 2.

> 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.


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Renato Golin via llvm-dev
Sent: Friday, October 30, 2020 8:45 AM
To: LLVM Dev <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] Policy on support tiers

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/3f0b71fd/attachment-0001.html>