[llvm-dev] Policy on support tiers

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 30 16:59:12 PDT 2020


On Fri, 30 Oct 2020 at 18:57, Geoffrey Martin-Noble <gcmn at google.com> wrote:

> I think bit rot is never really totally "irrelevant". Perhaps "detached
> and small enough that bit rot is a minor concern"?
>

Good point. Minor concern is a good alternative.

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

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.

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.


> Some additional constraints I would add:
> 1. Something in a higher tier may never depend on something in a lower
> tier.
> 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).
> 3. Items in tiers <1 must have clear documentation accompanying them
> indicating their less-supported status.
>

All good suggestions, thanks!

--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/0c5375c3/attachment.html>


More information about the llvm-dev mailing list