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

[Chris Lattner via llvm-dev]

On Jun 22, 2020, at 1:31 AM, Alex Denisov <1101.debian at gmail.com> wrote:
> 
> Hi Chris, hi folks,
> 
> The idea is great, obviously :)
> 
> Here are some questions/concerns regarding the development process of such projects.
> 
> TL;DR: we need to outline development process and create some template for the new incubated projects.
> 
> 1. Can those projects use pull requests?
> If yes, then would they have to switch to the Phabricator as soon as they land in the monorepo?
> If not, would they have to start with the Phabricator from the very beginning?
> Either way, it could be a barrier/needless overhead for contributors.
> 
> 2. Build system integration.
> If I understand correctly, projects in the monorepo should strictly follow the LLVM’s approach to CMake.
> This implies some limitations, or additional overhead for the maintainers if they want to overcome those limitations.
> Anyhow, I think it is necessary to have a template for new projects that want to participate in the incubator program.
> 
> 3. Continuous Integration
> Currently, there is a number of great services that provide CI for OSS projects, while LLVM uses its own infrastructure for that.
> So which CI system the projects should use? Extending LLVM infra for each incubated projects seems to be an overhead for the infra team.
> On the other hand, maintainers would have to migrate their CI setup to the LLVM infra as soon as the project gets into the monorepo.
> 
> The concerns are coming from a practical experience: if I would want to include Mull[1] into LLVM at this stage, then I have to:
> 
> - rewrite the build system
> - give up pull requests
> - give up CI setup and
> - (as the consequence) give up nightly builds and easy binary distribution
> - reformat the source code :-D
> 
> [1] https://github.com/mull-project/mull

Hi Alex,

I think we should be more flexible than projects in the mono repo about all of these topics.  I agree with your concern that being overly prescriptive isn’t necessarily helpful, but some things like license and CoC are requirements. I phrased this in terms of “Should” vs “Must” requirements in the draft with the understanding that we can negotiate the “should” requirements on a case-by-case basis depending on the needs of the project.

-Chris

> 
>> On 21. Jun 2020, at 00:42, 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).  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
>