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>
+Geoffrey Martin-Noble <gcmn at google.com> On Fri, Oct 30, 2020 at 8:45 AM Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/38c64d6c/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4000 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/38c64d6c/attachment-0001.bin>
Geoffrey Martin-Noble via llvm-dev
2020-Oct-30 18:57 UTC
[llvm-dev] Policy on support tiers
On Fri, Oct 30, 2020 at 11:36 AM Jacques Pienaar <jpienaar at google.com> wrote:> +Geoffrey Martin-Noble <gcmn at google.com> > > On Fri, Oct 30, 2020 at 8:45 AM Renato Golin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 >> >> I think bit rot is never really totally "irrelevant". Perhaps "detachedand small enough that bit rot is a minor concern"?> 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. >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >Thanks for kicking this off Renato. This looks very similar to what I would've written after that discussion except that I'm not sure I see the clear distinction between when something should be considered tier 2 vs 3. It seems like if something is sufficiently big it's not *allowed* to be tier 3 and must have a buildbot and remain green? And tier 2 seems to be largely an extension of the "experimental targets" policy, but encompassing things that aren't targets. Some additional constraints I would add: 1. Something in a higher tier may never depend on something in a lower tier. 2. Items in tiers <1 must always be simple to remove (`rm -rf /path/to/thing` ideally, although experimental backends also include some CMake options). 3. Items in tiers <1 must have clear documentation accompanying them indicating their less-supported status. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/6532eaa2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3992 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/6532eaa2/attachment.bin>