<div dir="ltr"><div dir="ltr">On Sat, 31 Oct 2020 at 10:52, antlists <<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</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">Tier 1 is LLVM.<br></blockquote><div><br></div><div>It's hard to define what LLVM is. There are things in the "llvm" directory that would definitely belong to lower tiers (helper scripts, build files, experimental code). Experimental back ends shouldn't break core LLVM, but they remain in "llvm/lib/Target" together with others.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Tier 2 is Clang, and Cmake, and all the other stuff that was mentioned <br></blockquote><div><br></div><div>I'd say clang and lld, lldb, RT, libcxx are all tier 1. Flang, once it reaches production quality, will also, but not because of the tier system, because of the experimental policy.</div><div><br></div><div>I want to make sure it's clear I'm not (yet) proposing a tiered system to extend the experimental or incubator policies.</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">
that is a first class citizen and supported as part of the project.<br>
Tier 3 is maybe incubator projects heading for tier 2<br></blockquote><div><br></div><div>I may be wrong, but I personally don't think we should include incubator projects here. My main concern is the mono-repo and whatever wants to "get in" needs to follow the same rules.</div><div><br></div><div>Incubator projects are by definition user or LLVM and we already have a (similar) policy for those.</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">Tier 4 is projects like Bazel which we have no intention of supporting <br>
but are best supported as part of the project ...<br></blockquote><div><br></div><div>I think this is where it gets fuzzy. I personally have no intention of supporting Bazel, but there are many people in the community that very much do. I would be sad if Vim support broke, and would probably try to fix it as soon as possible, but I'm aware that not everyone is enlightened in their choice of editors like me. :D</div><div><br></div><div>In summary, I don't think the message is "we have no intention of supporting", but "only part of the community will support, and therefore, that part of the community is responsible for not making it break other parts".</div><div><br></div><div>Perhaps having a numbered tier structure sends the wrong message. Perhaps we should have one core tier that everyone *must* care about, and satellite tiers that are just different subsets of the community.</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">And so on. That way, the rules are consistent everywhere, and if some <br>
other class of project appears, we can just slot them straight in by <br>
creating a new tier.</blockquote><div><br></div><div>Right. If we have only two tiers, but the second tier covers all subsets and all new stuff that is not core would be a "satellite", the policy would be simpler to state and keep. </div><div><br></div><div>If much later on we extend the satellite concept to experimental and incubator projects, this could be the thread that leads to a unified policy. </div><div><br></div><div>But only after we reach a consensus on what we think a tier is. Probably even after we write a tier policy and let it simmer for a while. Definitely not in this thread.</div><div><br></div><div>--renato</div></div></div>