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>