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

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> 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> 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
>> 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
>

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 thread. 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.

James
On Wed, 27 Jul 2016 at 19:33, Justin Lebar <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> 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> 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
> >> 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/20160727/f5d9a49b/attachment.html>

> On Jul 27, 2016, at 11:38 AM, James Molloy via llvm-dev <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
- 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
- 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

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
- 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
- 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
- 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
- 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
- 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
> 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/7db0a142/attachment-0003.html>

On 27 July 2016 at 19:38, James Molloy via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I thought it important because I don't believe you'll build
consensus in
> this thread. 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.
I also recommend writing up a summary (in a new thread?), so that
people can start fresh and not need to read the whole thread to know
all the discussions that were had.

And, as soon as possible, begin to write the proposal as a document,
so we can have it up the website. :)

cheers,
--renato