Tom Stellard via llvm-dev
2018-Nov-15 21:07 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
On 10/31/2018 03:02 PM, Justin Bogner wrote:> Tom Stellard <tstellar at redhat.com> writes: >>> On 10/31/2018 10:39 AM, Justin Bogner wrote: >>>> Tom Stellard <tstellar at redhat.com> writes: >>>>> On 10/31/2018 09:22 AM, Justin Bogner via llvm-dev wrote: >>>>>> Hi all, >>>>>> >>>>>> I've spent some time in the last couple of days trying to figure out how >>>>>> to adopt the [LLVM git monorepo prototype] for an out of tree backend. >>>>>> TLDR: I'm not convinced that this prototype is the right approach to >>>>>> converting to the monorepo, and I have a possible alternative. >>>>>> >>>>> >>>>> I think it's too late at this point to start considering alternative >>>>> monorepo layouts. We're already behind in getting the current monorepo >>>>> up and running, and I think discussing and implementing an alternative >>>>> will take too long and put our goal of moving off SVN by next year's >>>>> development meeting at risk. >>>> >>>> The layout here is not at all different, only the process by which the >>>> repo is generated. I strongly believe that a history preserving >>>> conversion is very important if we want to avoid making porting >>>> out-of-tree work horribly disruptive. >>> >>> The process is actually what I'm concerned about here, much more so than >>> the physical layout of the repo. It takes time to discuss, develop >>> and debug a new process for automatically syncing from SVN to a new git >>> repository. We've already gone through all these steps with the existing >>> monorepo, so switching to something else at this point would be a step >>> backwards in my opinion. > > I appreciate the amount of effort you and others have put in to get us > this far, but in my opinion these steps are not quite complete. A lot of > people have just started actually trying to merge with the monorepo > prototype since it was announced that it's intended to be the official > one last week. While there's certainly been a lot of discussion about > the monorepo in general in the last couple of years, I really hadn't > seen much serious discussion in public about the actual conversion until > the "New LLVM git repository conversion prototype" thread earlier this > month. > > Just to elaborate a bit on why I think this is important, I think the > difference between the two approaches to conversion have to do with what > we consider the real source of truth in our repository history. The > current prototype rebuilds everything with SVN as a source of truth and > throws out the official git mirrors, which sounds nice in theory, but > has pragmatic problems. The reality is that a lot of people have been > basing work off the git mirrors for a number of years now, so throwing > away that history causes real world problems. > > Mehdi AMINI <joker.eph at gmail.com> writes: >> At this point we can still consider it, I highly doubt that waiting a few >> weeks would jeopardize the one year deadline (that is really not that >> ambitious). >> >> What we should do though in my opinion is go with strict deadlines: i.e. >> every stage of discussion should be open for a very limited time. >> The current linear repo has the edge, but we for example we could leave >> this "zipper" proposal open for the next 1 week (or 2 if you want) as an >> RFC. Unless this alternative gets a high traction then we should close and >> move with the linear history repo. >> >> After almost two years of more or less stagnation, I feel it'd be >> unfortunate to rush right now on what I perceive as important design point >> (especially for downstream users) like this one. > > I agree with this. I'd appreciate if we give this a bit of time for > other people to weigh in - I suspect others are hitting the same issues > as I in trying to integrate with this version of the monorepo. >What is the status with this proposal? It has been 2 weeks now since the initial email and it seems like the discussion is slowing down. Do we still want to consider this zippered approach as a possibility for the official repo? Is the zippering tool proposed here[1] sufficient for out-of-tree git users? I think it's important to make a decision on this soon. I know a year seems like a long time to migrate, but with the holiday season approaching in the US it's going to be down to 9 months before we know it. -Tom [1] http://lists.llvm.org/pipermail/llvm-dev/2018-November/127704.html
David Greene via llvm-dev
2018-Nov-15 22:05 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes:> What is the status with this proposal? It has been 2 weeks now since > the initial email and it seems like the discussion is slowing down. Do > we still want to consider this zippered approach as a possibility for the > official repo?I have very strong feedback from the engineer who does our upstream merges that he does NOT want to see this zippered repository. A clean linear history makes understanding merges much easier. James made a number of other important points about limitations of the zippered repository: http://lists.llvm.org/pipermail/llvm-dev/2018-November/127460.html git-bisect being more complicated is a deal-breaker for me. Checking out a random commit and only getting part of the project is just odd. -David
James Y Knight via llvm-dev
2018-Nov-15 22:54 UTC
[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo
Based on the feedback so far, I propose that we call this discussion done -- we will not go with this zippered proposal, but will proceed with https://github.com/llvm-git-prototype/llvm/. On Thu, Nov 15, 2018 at 5:06 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > What is the status with this proposal? It has been 2 weeks now since > > the initial email and it seems like the discussion is slowing down. Do > > we still want to consider this zippered approach as a possibility for the > > official repo? > > I have very strong feedback from the engineer who does our upstream > merges that he does NOT want to see this zippered repository. A clean > linear history makes understanding merges much easier. > > James made a number of other important points about limitations of the > zippered repository: > > http://lists.llvm.org/pipermail/llvm-dev/2018-November/127460.html > > git-bisect being more complicated is a deal-breaker for me. Checking > out a random commit and only getting part of the project is just odd. > > -David > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://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/20181115/cb4b1386/attachment.html>
Maybe Matching Threads
- RFC: Dealing with out of tree changes and the LLVM git monorepo
- RFC: Dealing with out of tree changes and the LLVM git monorepo
- RFC: Dealing with out of tree changes and the LLVM git monorepo
- RFC: Dealing with out of tree changes and the LLVM git monorepo
- RFC: Dealing with out of tree changes and the LLVM git monorepo