[RFC] Introduce an LLVM "Incubator" Process

Thanks all for the great points - Stella and I wrote up a specific draft to answer the questions here. I just sent an email to start a new llvm-dev thread with a specific draft we can iterate on - drawing in a bunch of the feedback from this thread. Thank you for the great feedback!


Hi Chris, hi folks,

The idea is great, obviously :slight_smile:

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 :smiley:

[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.