[llvm-dev] Policy on support tiers
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Sat Oct 31 05:05:11 PDT 2020
On Sat, 31 Oct 2020 at 10:52, antlists <antlists at youngman.org.uk> wrote:
> Tier 1 is LLVM.
>
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.
> Tier 2 is Clang, and Cmake, and all the other stuff that was mentioned
>
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.
I want to make sure it's clear I'm not (yet) proposing a tiered system to
extend the experimental or incubator policies.
> that is a first class citizen and supported as part of the project.
> Tier 3 is maybe incubator projects heading for tier 2
>
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.
Incubator projects are by definition user or LLVM and we already have a
(similar) policy for those.
Tier 4 is projects like Bazel which we have no intention of supporting
> but are best supported as part of the project ...
>
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
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".
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.
And so on. That way, the rules are consistent everywhere, and if some
> other class of project appears, we can just slot them straight in by
> creating a new tier.
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.
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.
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.
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201031/47710025/attachment.html>
More information about the llvm-dev
mailing list