[llvm-dev] [RFC] Introduce an LLVM "Incubator" Process

Tue Jun 23 11:54:09 PDT 2020

On Tue, Jun 23, 2020 at 11:22 AM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Generally +1 on the idea.
>
> 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.
>
> 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:
>
>    - 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.
>    - 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?)
>
>
Fwiw, the ASF Incubator has guidelines to similar ends:
http://incubator.apache.org/guides/branding.html (see specifically the
"Disclaimers").

>
>
> 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.)
>
> Philip
> On 6/20/20 3:42 PM, Chris Lattner via llvm-dev wrote:
>
> Hi all,
>
> 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.
>
> 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.
>
> A former colleague recently suggested the idea of introducing an incubator
> process of some sort (e.g. xref the Apache version of this idea
> <https://incubator.apache.org/>).  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.
>
> Here is a sketch of how this could work:
>
>  - We maintain the same high bar to get into the LLVM monorepo, LLVM CI
> etc.  No change here.
>
>  - 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.
>
>  - 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.
>
>  - When the project is ready to graduate, it would follow the existing
> process for becoming a first-class part of the mono repo.
>
>  - 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).
>
>  - 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.
>
> What do you think?  Is anyone interested in helping to write up a more
> detailed proposal?
>
> -Chris
>
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200623/084853ea/attachment.html>