<div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Here it goes.</div><div><br></div><div>*** Tier 1: the core compiler, which *must* work at all times.<br></div><div>  * Front-ends, back-ends, middle-ends, libraries, core APIs, official projects and tools.</div><div>  * The CMake build infrastructure.</div><div>  * Builds on all first class citizen combinations of targets x OSs. [2]</div><div>  * Vim support (kidding!! :)</div><div><br></div><div>It must:</div><div>  * have noisy green bots</div><div>  * revert on failure policy</div><div>  * etc?</div><div><br></div><div>*** Tier 2: side projects that integrate with the compiler and that *should* work at all times.</div><div>  * Experimental targets, infrastructure and APIs, non-default cmd-line options</div><div>  * Alternative build systems (ex. GN, Bazel)</div><div><br></div><div>It must not:</div><div>  * Break or hinder tier 1</div><div>  * Increase validation noise beyond its scope</div><div><br></div><div>It should:</div><div>  * Have green buildbots, handled by the sub-community that cares about it</div><div>  * Have notifications only to those interested when things break (avoid bitrot)</div><div><br></div><div>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.<br></div><div><br></div><div>*** Tier 3: miscellaneous accessories</div><div>  * Helper scripts, editor files, debugger scripts, etc.</div><div>  * Whatever is detached enough that bit rot is irrelevant</div><div><br></div><div>It must not:</div><div>  * Break or hinder tiers 1 or 2</div><div>  * Increase validation noise beyond its scope</div><div><br></div><div>It should:</div><div>  * Have a sub-community that cares about it and maintain it</div><div><br></div><div>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.</div><div><br></div><div>cheers,</div><div>--renato</div><div><br></div><div><div>[1] <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-October/146138.html">http://lists.llvm.org/pipermail/llvm-dev/2020-October/146138.html</a></div><div>[2] Existing definition of "first-class", could be updated / moved here.</div><div></div></div></div>