<div dir="ltr"><div dir="ltr">On Sat, 31 Oct 2020 at 00:11, Geoffrey Martin-Noble <<a href="mailto:gcmn@google.com">gcmn@google.com</a>> wrote:<br></div><div class="gmail_quote"><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"><div dir="ltr">Yeah I think I have a similar *feeling* about the two categories, but couldn't really see logically what it was or why it necessarily implied a hierarchy. Like the hierarchy would suggest to me that something from tier3 could be "upgraded" to tier2, just as an experimental tier2 target could become tier1, but I'm not sure it really makes sense that there would actually be any movement between those tiers.</div></div></blockquote><div><br></div><div>Ah, I see the confusion. I didn't mean 2 is "better" than 3, just that it should be harder to remove stuff in tier 2 than stuff in tier 3, even if they bitrot a bit. I don't see *any* routes of "promotion" between tiers.</div><div><br></div><div>For example, a (completely hypothetical) replacement of CMake with Bazel would need a whole new series of RFCs and years of work that doesn't count like a promotion, but an entirely new work.</div><div> <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"><div dir="ltr">I think the point you articulated makes sense. Something that degrades gracefully doesn't need to have as much support commitment.</div></div></blockquote><div><br></div><div>There's the term I was looking for: "degrades gracefully". Thanks! :)</div><div><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"><div dir="ltr"> I guess the tiers are not about the level of the support something receives so much as the level of support that is *required* for it to be allowed in the repo. Editor configs just need some people to care about them and keep them reasonably up to date, whereas experimental targets or build systems also need people to agree that they will keep them green (plus the requirements already described in <a href="https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target" target="_blank">https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target</a>). I think code size is also a reasonable proxy for this.<br></div></div></blockquote><div><br></div><div>Exactly!</div><div><br></div><div>--renato</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"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
</blockquote></div></div>