[llvm-dev] [RFC] One or many git repositories?

Wed Jul 27 12:25:27 PDT 2016

> On Jul 27, 2016, at 12:10 PM, James Molloy <james at jamesmolloy.co.uk> wrote:
> 
> Hi Mehdi,
> 
> Thanks so much for writing this up! This will help many people who are struggling to keep up with the post influx including myself :)
> 
> > gives insights to the most common workflows
> 
> I must disagree with you here and this is the basis of all my messages; it gives an insight into workflows but not their commonality.

Oh you’re right, I didn’t mean to use the discussion to establish “how much a workflow is common”, my hope is that if a workflow is “common” enough, at least one dev would ask “How will we do XXX with this proposal?”, so that no “common” workflow goes unnoticed.

With that, the proposals will have to make some tradeoff, probably based on *assumptions* about the “commonality” of these workflows. A future survey should give better data on these “assumptions”.

— 
Mehdi

>  Only their commonality among those who spoke up. That's why I believe it should be *supplemented* with a survey of some kind. That is all I was trying to say :)
> 
> James
> 
> On Wed, 27 Jul 2016 at 19:47, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> On Jul 27, 2016, at 11:38 AM, James Molloy via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
> 
>> Hi Justin,
>> 
>> Firstly I really appreciate you taking the mantle and pushing this forward! Like Justin B I'll be bowing out after this. 
>> 
> 
>> I thought it important because I don't believe you'll build consensus in this threathese thred.
> 
> Is it possible to reach “consensus” on such issues? 
> 
>> I think the best that can be hoped for is opposition to give up fighting; advantages are to be had on both sides by different types of user and we've seen that many times in this thread. 
> 
> At some point there will be a need to acknowledges priority, people have conflicting workflow/goals and we’ll have to make a choice to favor one workflow instead of another.
> 
> I value a lot threads because it gives a lot of insights on the most common workflows and we can build a proposal that account for *most* and reduce as much as possible the inconvenience for the others.
> 
> Here is what I gathered till now:
> 
> About git itself:
> 
> - Aaron Ballman (with +1 from George Rimar): "Not everyone thinks git is a step forward. Please do not force people to use a "git-only" solution.”  (It seems that github has a SVN R/W access) http://lists.llvm.org/pipermail/llvm-dev/2016-May/100318.html <http://lists.llvm.org/pipermail/llvm-dev/2016-May/100318.html>
> - Joerg Sonnenberger: does not like git and prefer mercurial, didn’t find an email with a rational though.
> - Chris Matthews:  LNT / llvmlab-bisect needs currently a sequential ID number http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html <http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html>
> - Mehmet Erol Sanliturk: "I consider revision numbers as only a disastrous design” http://lists.llvm.org/pipermail/llvm-dev/2016-May/100329.html <http://lists.llvm.org/pipermail/llvm-dev/2016-May/100329.html> (+some criticism of the GitHub UI). 
> - Scott Warren: "find [git] immature, hard to use, and unreliable.” http://lists.llvm.org/pipermail/llvm-dev/2016-June/100514.html <http://lists.llvm.org/pipermail/llvm-dev/2016-June/100514.html>
> 
> About monorepo vs submodules:
> 
> - [multiple people]: need the ability to bisect (right now it’s not ideal and people are cloning the github monorepo). Both solution allows this, but some annoyance with submodules were countered with “developers don’t need to checkout the umbrella repo” which does not line up. Joerg mentioned as well “my primary interaction with the VCS for me is bisection, anything making it more fragile or more difficult to work is a huge no” (against submodules).
> - Justin Lebar: opening this thread with many arguments in favor of the monorepo: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102602.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102602.html>
> - Paul Robinson: "major drawback of a single huge repo IMHO: In git, to push a commit you must have it at the remote HEAD. If HEAD has changed you need to rebase/rebuild/retest/retry. With a single monster repo, a commit to 'lld' means I have to go through this pain to put in my 'clang' tweak.”,  http://lists.llvm.org/pipermail/llvm-dev/2016-July/102656.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102656.html>
> - Justin Bogner: " it's easy[1] to manage the set of repos with a script that cd's to each one and runs whatever git command.” And " if all of the repos are combined into one, you have to do work when you only want some of them. In my experience, this is basically always”. http://lists.llvm.org/pipermail/llvm-dev/2016-July/102609.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102609.html> 
> - Mehdi: "the minor inconvenience in the case of the monolithic repository is happening during the initial setup/clone/checkout, and not during day-to-day development (git pull, git checkout -b, git commit, git push), while the split model induces “minor inconveniences” in the day-to-day developer interaction. I.e. I prefer using a script to checkout and setup the repo, and then be able to use the standard git commands for interacting with it.” http://lists.llvm.org/pipermail/llvm-dev/2016-July/102612.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102612.html>
> - Chris Bienemann: What about a contributor only wanting to contribute to compiler-rt? He has to pay the price of cloning the full repo. http://lists.llvm.org/pipermail/llvm-dev/2016-July/103052.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/103052.html>
> 
> 
> On linear history and sequential revision number:
> 
> - [multiple people]: we should keep a linear history (haven’t found good reasons). Note that no Github proposal (submodule or monorepo) are addressing this. Tim proposed a solution based on checked-status but it requires every developer to run a script on their local machine before any push.
> - Chris Lattner: "I think we *want* to severely limit how history is allowed to look.  We don’t want the entire development history of your long-lived branch coming to mainline.” http://lists.llvm.org/pipermail/llvm-dev/2016-June/100665.html <http://lists.llvm.org/pipermail/llvm-dev/2016-June/100665.html>
> - Mehdi: "bug is fixed in r12345, my binary says "clang -v" is r23456 [or bot says it tested r23456], if I observe the bug [or the bot still fails] I know there is a problem immediately."
> 
> 
> — 
> Mehdi
> 
> 
> 
> 
> 
>> 
>> James
>> On Wed, 27 Jul 2016 at 19:33, Justin Lebar <jlebar at google.com <mailto:jlebar at google.com>> wrote:
>> Maybe we can hit the pause button on this issue of a survey vs
>> consensus-building.  I think it's a distraction from the main issue
>> here, and it makes it harder for everyone else to participate in the
>> thread.
>> 
>> That said, I really do think that perspectives like Justin B's below
>> are important.  That is, if people have a problem with the monorepo,
>> it is useful they can join the thread and say why.  That's true
>> regardless of whether we use a survey or not.
>> 
>> -Justin
>> 
>> On Wed, Jul 27, 2016 at 11:29 AM, James Molloy via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> > Hi,
>> >
>> > That's why we collate responses and provide summaries and proposals, which
>> > is what Renato did. There are a lot of technical deep dives on this thread
>> > that make it difficult to keep track of where consensus is going.
>> >
>> > Besides which we surely care about all our users and developers, and not
>> > just the loud ones or ones with enough cajones to chip in on a massive
>> > thread full of big names without fear of embarrassing themselves. We also
>> > surely don't want a slew of '+1 to the proposal 93 replies ago'; how does
>> > that help anyone decide if consensus is reached?
>> >
>> > How can you decide that people who don't see this thread don't get the
>> > chance to vote? It's summer time and people *will* be on vacation. Do you
>> > expect them to find this in their inbox when they come back and read through
>> > every response? This is not realistic.
>> >
>> > James
>> >
>> > On Wed, 27 Jul 2016 at 19:23, Krzysztof Parzyszek via llvm-dev
>> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> >>
>> >> On 7/27/2016 1:04 PM, James Molloy via llvm-dev wrote:
>> >> > This thread is not particularly inviting. It has over 300 replies at the
>> >> > time of writing and we don't all have the time to delve into such a
>> >> > quagmire. That doesn't mean our opinions are worthless.
>> >>
>> >> It doesn't take reading all responses to see where the discussion is
>> >> going. Important decisions take time to make. People took a lot of
>> >> effort in this thread to present their ideas and to address various
>> >> concerns. I bet they all have other things to do as well.
>> >>
>> >> -Krzysztof
>> >>
>> >> --
>> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> >> hosted by The Linux Foundation
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> >
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20160727/a3445d3e/attachment.html>