[llvm-dev] [Incubation] Request to incubate mlir-npcomp

[Stephen Neuendorffer via llvm-dev]

On Thu, Jun 25, 2020 at 8:27 AM Nicolai Hähnle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Jun 24, 2020 at 8:16 PM Sean Silva <silvasean at google.com> wrote:
> > On Wed, Jun 24, 2020 at 9:54 AM Nicolai Hähnle <nhaehnle at gmail.com>
> wrote:
> >> On Tue, Jun 23, 2020 at 2:40 PM Stella Laurenzo via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >> > We originally started it as a fork of the LLVM repository, but
> transitioned to the MLIR standalone template, and we found it more
> productive to iterate out of tree in this fashion, bumping to the latest
> LLVM version every week or so as needed (note: the ability to exist out of
> tree for MLIR dependent projects is actually quite good, and the more of us
> who do it, the better it becomes).
> >>
> >> How do you deal with the problem of using the "right" LLVM version? As
> >> somebody who spends a significant amount of time on a project that is
> >> open-source but out-of-tree -- and for good reasons that mean we're
> >> unlikely to want to incubate in this fashion -- I find this to be a
> >> major problem.
> >>
> >> If the goal of incubation is to eventually become part of the
> >> llvm-project monorepo, I feel that being inside the monorepo should be
> >> a goal early on.
> >
> >
> > Actually that would be a big problem in practice, because it means that
> either:
> > 1. random changes in the monorepo can put the incubator into an
> unbuildable state
> > 2. people changing the monorepo need to somehow build and test and fix
> incubator projects
>
> I think you misunderstood. The idea isn't to have the incubated
> project in github.com/llvm/llvm-project. It's that the incubator
> project is a _fork_ of llvm-project.
>
>
> > Currently, in npcomp, we have a monorepo hash that we bump periodically.
> That means that people can follow our README and build our project at any
> point by checking out the right monorepo revision. Npcomp developers have
> the responsibility of fixing our own code as LLVM updates.
>
> I suppose this works, though it seems to me that this is strictly less
> convenient than having the project be a fork and just merging the
> llvm-project master periodically instead of changing the README and
> forcing everybody to update their llvm-project checkout associated to
> the project manually.
>
>
I think the main consideration here should be what happens when it becomes
time to integrate into LLVM.
There are several possibilities:
1) do a merge commit, preserving the history correctly, including any
modifications to LLVM.  This is probably not a good idea because: 1) we
suddenly get lots of non-linear history and 2) the modifications to LLVM
over time probably need to get reviewed.  This is only really possible with
a 'fork'
2) Use branch rewriting like MLIR/Flang.  This keeps the commit history of
the incubator, but loses the ability to bisect the incubator before the
merge.  This is only really possible if things start out of tree.
3) Squash the history of the incubator and apply it as a single commit.
This obviously loses the history.  This is probably possible developing as
a fork or out of tree, but might require a significantly large integration
patch.  It can also be used to consolidate changes to LLVM, but those would
still require review which might be difficult.

Generally, I think #2 has been a reasonably successful model.  MLIR did not
store a hash, but attempted to stay at head, which made it somewhat more
difficult to keep up with the pace of development.  I would recommend
working out of tree for most incubated projects and encourage teams to push
modifications to the LLVM core upstream early rather than later.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200625/6e60873c/attachment.html>