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

[Stellar Accident via llvm-dev]

On Sun, Jun 21, 2020, 1:57 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

>
> On Sun, Jun 21, 2020 at 12:24 PM Stellar Accident via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Thanks Chris. As the "former colleague" my +1 is a bit implied :)
>>
>> I took the liberty of drafting an actual proposal doc:
>> https://github.com/stellaraccident/llvm-www/blob/master/proposals/LP0002-LLVMIncubator.md
>>
>> From a process perspective, I'm not entirely clear on the next steps here
>> (and this is the first proposal after the proposal to have a proposal
>> process -- so I guess we're dogfooding it). In my mind, even though there
>> seems to be consensus on this RFC thread to move forward, this seems like a
>> large enough change that we should commit a proposal to memorialize it (I
>> imagine we're going to revise it over the years, and the history will be
>> useful). Should I create a separate "PITCH" thread or just commit a version
>> of the above proposal for further revision? I'm also happy to send it out
>> for an actual review but have actually never made changes to the llvm-www
>> repo and don't know how we review such things.
>>
>
> My understanding of the proposed process is that the proposal/PITCH
> process is only happening on controversial RFCs:
>
> > If it can be resolved through normal means, great - no need for
> additional process. We expect this to continue to be the common case. If a
> discussion turns controversial, escalate the RFC into a "proposal pitch",
> to help frame both sides of the discussion.
>
> The current RFC thread does not seem to have reached this point.
>

Sg - wasn't looking to add process, but it was suggested OT that if I had
the time, it might be useful to write a proposal doc. And then that is
where I found the (new) proposal process.

It seems like the proposal process was created primarily for formalizing
decision making for controversial items. Is it possible that it can/should
also be used to memorialize "significant" policy decisions (even if not
controversial)?


> --
> Mehdi
>
>
>
>>
>> Happy to do whatever to move this forward!
>>
>> 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.
>>>
>>>  - 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
>>>
>> _______________________________________________
>> 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/65671f3a/attachment.html>