<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks all for the great points - Stella and I wrote up a specific draft to answer the questions here. I just sent an email to start a new llvm-dev thread with a specific draft we can iterate on - drawing in a bunch of the feedback from this thread. Thank you for the great feedback!<div class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2020, at 11:54 AM, Stella Laurenzo <<a href="mailto:stellaraccident@gmail.com" class="">stellaraccident@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 23, 2020 at 11:22 AM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><p class="">Generally +1 on the idea.</p><p class="">This does sound like an extension of the existing "experimental
backend" idea. At least at first, it sounds like the two are
separate - experimental backends live in monorepo, incubation
projects don't - but there's definitely some experience we can
learn from and adapt.</p><p class="">One concern I have is about fragmentation and branding.
Specifically, I'm not sure an end state with a bunch of incubator
projects under the LLVM umbrella with distinct developer
communities is something we'd want to encourage. This might need
some discussion more broadly, but a few specific ideas:</p>
<ul class="">
<li class="">Maybe we should require each incubator proposal to have a
sponsor from within the existing community? This doesn't have
to be the lead or proposal author, but someone who already
contributes who stands up and says they think this is beneficial
to LLVM long term, and are willing to put some level (tbd) of
supervision and steering into it.</li>
<li class="">Maybe we should be careful on the wording we require for
describing such a project? Perception matters, and I'm hesitant
to see discussions about "bugs in LLVM" if one incubator has
quality issues. Maybe specifically require READMEs to be
explicit about incubation status and strong discourage the use
of "an LLVM project" and related phrases for incubators? (e.g.
Recommend "X, an LLVM incubator" instead?)</li></ul></div></blockquote><div class=""><br class=""></div><div class="">Fwiw, the ASF Incubator has guidelines to similar ends: <a href="http://incubator.apache.org/guides/branding.html" class="">http://incubator.apache.org/guides/branding.html</a> (see specifically the "Disclaimers").</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><ul class="">
</ul><p class="">If we're going to have looser standards for incubators, I think
we need to be very explicit about eventual "promotion". It needs
to be very clear in our definition of incubator which items must
be fixed for inclusion in mono-repo, and which items must be fixed
to be non-experimental. (If experimental is a distinct we
maintain at least.)</p><p class="">Philip<br class="">
</p>
<div class="">On 6/20/20 3:42 PM, Chris Lattner via
llvm-dev wrote:<br class="">
</div>
<blockquote type="cite" class="">
Hi all,
<div class=""><br class="">
</div>
<div class="">Today, we maintain a high bar for getting a new
subproject into LLVM: first a subproject has to be built far
enough along to “prove its worth” to be part of the LLVM
monorepo (e.g. demonstrate community, etc). Once conceptually
approved, it needs to follow all of the policies and practices
expected by an LLVM subproject.</div>
<div class=""><br class="">
</div>
<div class="">This is problematic for a couple reasons: it
implicitly means that projects have to start *somewhere else*
but proactively decide to follow LLVM design methodology and
principles in the hope of being accepted. It is sometimes
socially difficult to get these projects going because there are
many other forces that could encourage other practices. For
example, I personally encountered this at Google with MLIR -
“why aren’t you using Google coding standards?”, several of us
are currently discussing this in a new skunkworks project in the
“compilers for hardware” world, and the Flang and other projects
have found this challenging in the past. Once the project gets
to a point of critical mass with the “wrong” approach, it is
very difficult and expensive to convert to the LLVM style, and
from a social perspective, inertia sometimes leads to forking
off to separate projects instead of folding back in to LLVM.</div>
<div class=""><br class="">
</div>
<div class="">A former colleague recently suggested the idea of
introducing an incubator process of some sort (e.g. xref the <a href="https://incubator.apache.org/" target="_blank" class="">Apache version of this idea</a>). I
think this is a really interesting idea, and it is much easier
now that the majority of the “official” code is in the LLVM
monorepo.</div>
<div class=""><br class="">
</div>
<div class="">Here is a sketch of how this could work:</div>
<div class=""><br class="">
</div>
<div class=""> - We maintain the same high bar to get into the
LLVM monorepo, LLVM CI etc. No change here.</div>
<div class=""><br class="">
</div>
<div class=""> - We have a very light-weight proposal process that
allows people to create incubator projects in the LLVM
organization, with no code up front. The project would be
required to have e.g. a charter document and README.</div>
<div class=""><br class="">
</div>
<div class=""> - Such projects are required to follow the LLVM
developer policy, coding standards, CoC, etc, but can define
their own stability and evolution process, code owners, etc.</div>
<div class=""><br class="">
</div>
<div class=""> - When the project is ready to graduate, it would
follow the existing process for becoming a first-class part of
the mono repo.</div>
<div class=""><br class="">
</div>
<div class=""> - We have some policy on when to retire/delete
projects, which can be ironed out the first time it comes up
(e.g. start with a nomination).</div>
<div class=""><br class="">
</div>
<div class=""> - We could even try to help encourage new projects
to include a ‘mentor’ that has experience with the LLVM project
to help nudge things in the right direction and encourage proper
development approach.</div>
<div class=""><br class="">
</div>
<div class="">What do you think? Is anyone interested in helping
to write up a more detailed proposal?</div>
<div class=""><br class="">
</div>
<div class="">-Chris</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<fieldset class=""></fieldset>
<pre class="">_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div></div>
</div></blockquote></div><br class=""></div></body></html>