<div dir="ltr">Thanks Philip!<div><br></div><div>First draft at: <a href="https://reviews.llvm.org/D90761">https://reviews.llvm.org/D90761</a></div><div><br></div><div>Feel free to copy more people.</div><div><br></div><div>cheers,</div><div>--renato</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 3 Nov 2020 at 17:25, Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.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>
<p>Just want to chime in with support. I like the general direction
and agree with the suggest tweaks mentioned so far in this thread.</p>
<p>Philip<br>
</p>
<div>On 11/2/2020 3:56 PM, Eric Christopher
via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Sounds good, thanks! :)<br>
<div><br>
</div>
<div>-eric</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 6:49 PM
Renato Golin <<a href="mailto:rengolin@gmail.com" target="_blank">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="auto">Right, that's a good split, I think. Only
monorepo, minus experimental, unsupported build systems and
helper files.
<div dir="auto"><br>
</div>
<div dir="auto">I'll send another update tomorrow morning. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Thanks everyone! </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 2 Nov 2020, 20:38
Mehdi AMINI via llvm-dev, <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">
<div style="color:rgb(0,0,0)">Hi,</div>
<div style="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">Nice proposal Renato!
I'm very supportive of the direction in general.</div>
<div style="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">I share the sentiment of
Eric and Geoffrey in general though.</div>
<div style="color:rgb(0,0,0)">In particular, it wasn't
clear to me that something like flang for example
would be tier 2, I told the flang maintainer to feel
free to revert my patches when I break their bot for
example. I assumed that every subproject in the
monorepo was supported as long as they have public
bots. The only explicit unsupported things are the
experimental LLVM backends I believe?</div>
<div style="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">Thanks for iterating on
this! :)</div>
<div style="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">Cheers,</div>
<div style="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">-- </div>
<div style="color:rgb(0,0,0)">Mehdi</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at
12:33 PM Eric Christopher via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</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">I think I'd work at a little higher
level on the things. Explicit lists are hard to
maintain and, in general, I think we're looking at
guidelines rather than hard lists.
<div><br>
</div>
<div>-eric</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Nov 2,
2020 at 3:27 PM Geoffrey Martin-Noble <<a href="mailto:gcmn@google.com" rel="noreferrer" target="_blank">gcmn@google.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">I'm not super familiar with all the
various subprojects, but I'd be a little
hesitant to put e.g. libc and flang in the same
category as vim bindings or the gn build :-D I
think I've had failing pre-merge checks from
both flang and polly before, so at least in
practice they don't seem to be following the
guidelines you mention here. I don't know
whether this means that they should just be
moved up to tier 1, or whether they are actually
less-supported than some of the more established
projects. If their current behavior should
change, then that seems like a bigger
discussion.
<div><br>
</div>
<div>I also think it might be better to make
this focus specifically on the monorepo.
Incubator projects already have a clear policy
and a lot of the fine points here only make
sense in the context of the monorepo. e.g.
bots with blamelists targeting only a
subcommunity doesn't make much sense for a
separate repo. If you committed the the
mlir-npcomp repo I think you should get
notified if you broke something :-D</div>
<div><br>
</div>
<div>Apologies if the below falls into the
category of "writing", but here are some
additional thoughts:</div>
<div><br>
</div>
<div>I also think that the distinction we
previously had with tier 2 vs tier 3 was
useful in terms of differentiating things that
need quite a bit of promised support to be
allowed in the monorepo because they're
bigger, more complicated, and require constant
maintenance (e.g build systems) vs things that
can be checked in without much discussion
because they are small, simple, and degrade
gracefully (e.g. editor bindings). Maybe
separate tiers isn't the right way to do that,
but I think we should make that distinction
clear. Like if someone wants to check in
bindings for their editor of choice, a simple
patch seems appropriate, whereas if someone
(hypothetically ;-P) wants to propose a
secondary build system it should at least be
discussed on the mailing list. Maybe we can
just include language in the description of
tier 2, like:</div>
<div><br>
</div>
<div>When adding components intending for tier 2
status, the level of discussion and support
commitment required is proportional to the
size and complexity of the component. For
example:</div>
<div>1. editor bindings can be just be added as
a patch following the normal review process</div>
<div>2. more complex components like a secondary
build system should start as an RFC that
details how this component will be supported</div>
<div>3. Experimental backends have an entire
section on their introduction (link)</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Nov 2,
2020 at 11:58 AM Renato Golin <<a href="mailto:rengolin@gmail.com" rel="noreferrer" target="_blank">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">Ok, so after some feedback,
here's an updated version. Separate thread
as the previous got split.
<div><br>
</div>
<div>People seem to agree on the overall
terms, but there was confusion on the
difference between tier 2 and 3 as well as
clarification on what projects go where.</div>
<div><br>
</div>
<div>I have joined tiers 2 and 3 and made
explicit the three criteria they fit into,
with the requirements more formally
explained.</div>
<div><br>
</div>
<div>Please review the sub-project lists on
the two tiers, I'm not so sure about
them. </div>
<div><br>
</div>
<div>Once we're happy with the "what", I'll
send a review for a new doc so we can
discuss the writing and format there
(ignore it for now).</div>
<div><br>
</div>
<div>Here it goes:</div>
<div><br>
</div>
<div>*** Tier 1: the core compiler,
officially supported by the community.<br>
<br>
Rationale:<br>
* Common code that supports most
projects, upstream and downstream forks
and forms the toolchain itself.<br>
* Includes everything we release on all
architectures and OSs we have releases on.<br>
<br>
What:<br>
* LLVM itself, clang/tools, compiler-rt,
libcxx/abi/unwind, lld, lldb, openmp,
mlir.<br>
* Basically everything inside the
mono-repo that is not in tier 2.<br>
* Builds on all first class citizen
combinations of targets x OSs (incl.
test-suite).<br>
* The CMake build infrastructure and
release scripts.<br>
* Phabricator & Buildbot
infrastructure.<br>
* The test-suite repository.<br>
<br>
Requirements:<br>
* Follow all core development policies on
code quality, reviews, reverts, etc.<br>
* Noisy green buildbots, emailing all
developers.<br>
* Most not be broken by changes in tier 2
(ex. if they require tier 1 changes).<br>
* Bitrot will downgrade areas to tier 2
or be removed, depending if a
sub-community picks up support and has a
timeline to fix.<br>
<br>
*** Tier 2: side projects that integrate
with the compiler and that *should* work
at all times.<br>
<br>
Rationale:<br>
* Code that is making its way into LLVM
core (tier 1) via experimental/incubator
roadmaps, or;<br>
* Code that isn't meant to be in LLVM
core, but has a sub-community that
maintains it long term, or;<br>
* Code that is making its way out of LLVM
core (legacy) and that is a strong
candidate for removal.<br>
<br>
What:<br>
* Experimental targets/options.<br>
* Experimental mono-repo projects (flang,
libc, libclc, parallel-libs, polly,
beduginfo-tests?, pstl?)<br>
* Incubator projects (circt, mlir-npcomp,
etc).<br>
* Legacy tools (lnt).<br>
* Alternative build systems (gn, bazel).<br>
* Tool support (gdb scripts, editor
configuration, helper scripts).<br>
<br>
Requirements:<br>
* Follow all core development policies on
code quality, reviews, reverts, etc.<br>
* Infrastructure that only notify its
sub-community.<br>
* Most not break tier 1, promptly
reverting if it does, with discussions to
be done offline before reapply.<br>
* Leaner policy on bots being red for
longer, as long as the sub-community has a
roadmap to fix.<br>
* Leaner policy on bitrot, as long as it
doesn't impact tier 1 or other tier 2
projects.<br>
* Should be easy to remove (either
separate path, or clear impact in code).<br>
* Must have a document making clear
status, level of support and, if
applicable, roadmap into tier 1 / out of
LLVM.<br>
</div>
<div><br>
</div>
<div>
<div><br>
</div>
<div>cheers,</div>
<div>--renato</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
</blockquote></div>