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

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

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. 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>
wrote:
> 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
(+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
>
>
> 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>
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
>> >
>>
> _______________________________________________
> 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/3eb4d300/attachment.html>

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