[llvm-dev] Git Transition status?
Alexander Benikowski via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 17 07:09:34 PST 2017
>
> Some infrastructure is needed for this, but it's easy and automated
Well sounds like Submodules to me. Hasn't there been a discussion about it
in one of the first Gitposts?
2017-01-17 12:31 GMT+01:00 Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org
>:
> "The people most impacted by mono-repo are those who want to build just
> compiler-rt"
>
> Perhaps more accurate to say "Those who want to contribute only to
> compiler-rt"?
>
> Those who only want to build compiler-rt can check it out from a slave
> repo that mirrors commits to compiler-rt in the mono-repo. Some
> infrastructure is needed for this, but it's easy and automated.
>
> On Tue, Jan 17, 2017 at 4:17 AM, Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Jan 13, 2017, at 1:37 PM, Mehdi Amini via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> The main outcome of the BoF had the dev meeting was that we agree’d that
>> moving to GitHub was the best choice forward for LLVM (IIRC only one person
>> in the room expressed concerned about GitHub, but he said he had personal
>> grief with them and nothing specific for LLVM).
>>
>> The unknown that remains is: will we use a mono-repo or a multi-repo. On
>> this aspect:
>>
>> - We got consensus at the BoF that downstream users (i.e.
>> non-contributors) are not impacted by this choice, and we’re not gonna
>> optimize the repository structure for them.
>> - My reading of the survey is that the monorepo has a significant lead.
>> - My understanding of the dynamic of the discussions and question during
>> the BoF is that monorepo has a significant lead, is likely to satisfy more
>> people, and has a very small number of people concerned about it. On the
>> other hand many people have strong feeling about the multirepo.
>>
>>
>> FWIW, I have spoken to a large number of people about the mono vs
>> multi-repo tradeoffs, and I’m personally convinced that mono repo is the
>> way to go. For a few reasons:
>>
>> - Monorepo is the “natural” way to use git. Submodules are possible to
>> use, but add significant complexity.
>> - The download size of a mono-repo is manageable, and seems scalable for
>> a project the size of LLVM (including reasonable growth over the next 10
>> years).
>> - As Medhi says, according to surveys and discussions in forums like the
>> LLVM Dev Meeting BoF, most people who care are in favor of mono-repo.
>> - The people most impacted by mono-repo are those who want to build just
>> compiler-rt. We want these people to be happy, but they are very few in
>> number, and their benefit needs to be balanced against the benefit for the
>> larger community that builds llvm (and typically clang or another front
>> end).
>>
>> Overall, it seems clear that either approach could work, but mono seems
>> to win out because it is more popular and more simple. It would require
>> tweaks to LLVM’s cmake system though: instead of deciding to build a
>> subproject based on whether it is checked out, it should instead be based
>> on configuration time flags.
>>
>> -Chris
>>
>>
>>
>> Considering all the current tradeoffs, it is likely that we will move-on
>> with a monorepo, even if there are no guarantee or decision made at this
>> point.
>>
>> The path forward (already engaged) is to engage a prototype phase: we’re
>> building a monorepo and trying to make it usable as much as possible,
>> without making any change or building anything that would commit us to a
>> monorepo (for instance we’re not gonna migrate any bots to it).
>>
>> The goal of this prototype is that developers can start using a monorepo
>> to try it, and we can evaluate how it plays in practice, outside of
>> theoretical considerations. If anyone finds concerns about a given
>> workflow, we can study what can be improved to address it, or maybe we’ll
>> hit a wall that would show that monorepo can’t address what we think it
>> will.
>>
>> At some point, if the experiment is conclusive, we should be able to
>> build a larger majority and hopefully reach a consensus that the proposed
>> prototype can be considered viable for development and start planning the
>> actual committing changes.
>>
>> The monorepo is not totally ready yet, but you can already experience it
>> (I live on day-to-day for my development, and a few other people as well),
>> instructions are in the doc: http://llvm.org/docs/Gett
>> ingStarted.html#for-developers-to-work-with-a-git-monorepo
>>
>> I don’t have any schedule to announce, hopefully we can make it all
>> happen in 2017.
>>
>> Best,
>>
>> —
>> Mehdi
>>
>>
>> On Jan 13, 2017, at 1:07 PM, Keane, Erich via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all-
>> I was wondering if anyone knew what the status/schedule of the SVN to
>> git/github transition was? I thought I saw that at the November meeting it
>> was agreed upon, but I'm not sure I saw any progress since?
>>
>> Thanks,
>> Erich
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> _______________________________________________
> 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/20170117/43ad06aa/attachment-0001.html>
More information about the llvm-dev
mailing list