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

[Steve Scalpone via llvm-dev]

Had there been an llvm incubator process, I would have encouraged flang to apply.

Flang became an llvm subproject this spring after a few years of development in github/flang-compiler.

The llvm development process and tools are basically the same as what we had been using in github.  Transitioning to phabricator was not difficult.

The main technical difficulty with the transition was the integration of flang with the llvm build system (cmake files).  LLVM is big, the build system is complex, test builds are slow, and there are a great many different configurations that must be supported.

The volume of changes coming from llvm-project is huge compared to flang-compiler/f18 -- we dialed back our CI to only trigger builds when files under flang or mlir change.

 - Steve

On 6/22/20, 11:24 AM, "llvm-dev on behalf of Nicolai Hähnle via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote:

    External email: Use caution opening links or attachments


    On Sun, Jun 21, 2020 at 12:43 AM Chris Lattner via llvm-dev
    <llvm-dev at lists.llvm.org> wrote:
    >  - 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?

    This seems pretty reasonable. There is a technical process question:
    What does the incubator project's Git repository look like?
    Specifically, I would recommend that projects that are serious about
    this are started as a fork of the llvm-project mono-repository. They'd
    live as a separate GitHub repository in the github.com/llvm/
    organization, but share history. There'd be an expectation that such
    projects regularly merge LLVM master (or rebase on top of it, but that
    seems less likely for long-running projects) -- maybe once per LLVM
    release cycle initially, and then more frequently as the project
    becomes serious about being integrated in the monorepo. This allows an
    eventual smooth merging of the project while keeping all history
    without weird artefacts.

    Cheers,
    Nicolai



    --
    Lerne, wie die Welt wirklich ist,
    aber vergiss niemals, wie sie sein sollte.
    _______________________________________________
    LLVM Developers mailing list
    llvm-dev at lists.llvm.org
    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev