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

[Philip Reames via llvm-dev]

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?)

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 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/9fcd32fc/attachment.html>