[llvm-dev] Policy on support tiers

[Renato Golin via llvm-dev]

On Sat, 31 Oct 2020 at 00:11, Geoffrey Martin-Noble <gcmn at google.com> wrote:

> 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.
>

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.

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.


> I think the point you articulated makes sense. Something that degrades
> gracefully doesn't need to have as much support commitment.
>

There's the term I was looking for: "degrades gracefully". Thanks! :)

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
> https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target). I think
> code size is also a reasonable proxy for this.
>

Exactly!

--renato

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201031/91e0b225/attachment.html>