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

Sun Jun 21 14:56:48 PDT 2020

On Sun, Jun 21, 2020 at 2:04 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hey Chris,
>
>
> On Sat, Jun 20, 2020 at 3:43 PM Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> 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.
>>
>
> Since the "incubator" aspect of this is that these projects are intended
> to integrate the monorepo ultimately (or be deleted from the organization),
> that means that the charter when starting such a project should have
> consensus that it conceptually belongs to the monorepo ultimately, right? I
> assume this is the main part of the "light-weight proposal process"?
>

I think that logically follows, but I would be explicit about evaluating
proposals fairly pragmatically (and we could write down some guidelines).
There are multiple reasons that I have seen for wanting such incubation
repositories, and many of them fall more into the governance and
community-alignment category versus a strictly visible code connection to
the monorepo (from the outset). There is also an element to incubating new
things that creates a certain evolutionary expectation (i.e. might prompt
further thought or organizational work on the monorepo vs just a "it would
slot in here" kind of judgment). Also, I've seen a "what you can't see and
talk about, you can't collaborate on" theme that would bias me to have more
of a guideline-driven default accept policy vs consensus-based evaluation
of the technical details. It should be fairly easy to get in, and
consequently also, fairly easy to move out (in whole or part) if the
alignment doesn't emerge.

If you were to give me 60 seconds to formulate what my checklist for
consideration would be, here are some of the points:

   1. Is this expected to build on or extend by way of dependency an
   existing core LLVM project?
   2. If successful, could this project provide components that would be of
   use to a broader audience that uses LLVM technology?
   3. Are the project goals roughly "in kind" with other parts of LLVM
   (i.e. more language/compiler based rather than, say, word processor based)?
   4. Is there potential, tangible mutual advantage to having the LLVM
   Foundation's governance model applied to the project from its inception?
   5. Will the LLVM Foundation hosting this project aid LLVM contributors
   to better collaborate on the project?

If it were me voting, I would consider #4 and #5 to be sufficient to vote
yes, regardless of any ambiguity or unresolved issues about technical
alignment. That is all off the top of my head and not deeply thought
through.

So in short, at the outset, I would expect to at least be able to imagine a
future where some portion of the project graduates to the monorepo, but I
would be fairly lenient on being able to see the path from the outset.

>
>
>
>
>>
>>  - 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.
>>
>>
> +1 for me overall.
>
> Thanks,
>
> --
> Mehdi
>
>
>
>> 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
>>
> _______________________________________________
> 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/20200621/ee2256fa/attachment.html>