<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 30, 2020 at 4:59 PM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.com</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"><div dir="ltr">On Fri, 30 Oct 2020 at 18:57, Geoffrey Martin-Noble <<a href="mailto:gcmn@google.com" target="_blank" class="cremed">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 class="gmail_quote"><div dir="ltr" class="gmail_attr">I think bit rot is never really totally "irrelevant". Perhaps "detached and small enough that bit rot is a minor concern"? <br></div></div></div></blockquote><div><br></div><div>Good point. Minor concern is a good alternative.</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 class="gmail_quote"><div dir="ltr">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.</div></div></div></blockquote><div><br></div><div>Right, I think I'm trying to separate things that interact with the core code from the things that don't. I think this is important because the evolution of tier 2 should be a lot closer to mainline, while tier 3 could be many commits behind and still be useful, even if it needs patches to reapply to mainline. For example, when new files are added, the Bazel files need to change, while an editor or debugger configuration will be largely the same, and if not, it won't break anything other than the very specific usage that it was intended for.</div><div><br></div><div>Perhaps I'm going in circles, I hope someone has a better way of describing the difference. If not (ie it's just in my head), then I'd be happy to merge the two tiers in one.</div><div> </div></div></div></blockquote><div>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. Vim configs might be more widely used than gn build files, so it seems a bit strange that they're "lower tier", but I guess that may be true of experimental backends as well. I think the point you articulated makes sense. Something that degrades gracefully doesn't need to have as much support commitment. 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">https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target</a>). I think code size is also a reasonable proxy for this.</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"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Some additional constraints I would add:<br></div><div>1. Something in a higher tier may never depend on something in a lower tier.</div><div>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).</div><div>3. Items in tiers <1 must have clear documentation accompanying them indicating their less-supported status.</div></div></div></blockquote><div><br></div><div>All good suggestions, thanks!</div><div><br></div><div>--renato </div></div></div>
</blockquote></div></div>