<div dir="ltr"><a class="gmail_plusreply" id="plusReplyChip-6" href="mailto:gcmn@google.com" tabindex="-1">+Geoffrey Martin-Noble</a> <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 30, 2020 at 8:45 AM Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>