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

Renato Golin via llvm-dev
2016-07-30T09:28:33Z

Michael,

Can you guys do a similar format and location as the other one?

http://llvm.org/docs/Proposals/GitHubSubMod.html

There are still changes that may be made to this one, but we should keep
their formats, location and contents similar, to help with the comparison.

Cheers,
Renato

On 30 Jul 2016 7:56 a.m., "Michael Gottesman" <mgottesman at
apple.com> wrote:

> I talked with Majnemer/Mehdi about developing this proposal on github.
> They said that this was ok (after all we are moving to github). We can add
> facts to the specific proposal via PRs which we can use to center the
> discussion.
>
> I created a straw man repo and a scaffolding hacked from the
> swift-evolution process for just this purpose. I hacked some words from
> jlebar's initial email as just a starting point.
>
>
>
https://github.com/gottesmm/llvm-evolution/blob/master/proposals/0001-monorepo.md
>
> What do you guys think?
> Michael
>
> > On Jul 29, 2016, at 8:51 AM, Michael Gottesman <mgottesman at
apple.com>
> wrote:
> >
> > Additionally we should reach out to individual stakeholders and get
real
> data about:
> >
> > 1. Given the current workflow, what would it take to change to this
> different workflow. Whether or not it is easy or hard should be left out.
> Just specific details.
> >
> > 2. Once the workflow has been changed, how does this workflow change
day
> by day living for their users? Again this should be specific and a
> judgement of ease or difficulty should be left out.
> >
> > Without impartial data gathering, followed by compilation of the data,
> can an effective discussion happen.
> >
> > In fact I hope the proposal has an alternatives considered section
that
> lists all alternatives and a section that lists all impacts on other
> people, rather than just the specific proposal.
> >
> > Sent from my iPhone
> >
> >> On Jul 29, 2016, at 8:22 AM, Michael Gottesman via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> I agree with Renato here. From someone who is just beginning to
> participate in this thread, the sheer amount of ad hominem argument thrown
> about is disappointing and unhelpful. What we need is a specific proposal
> to center the discussion and then line by line review that breaks out into
> (potentially) more specific discussion on individual points if they are
> contentious.
> >>
> >> Sent from my iPhone
> >>
> >>> On Jul 29, 2016, at 7:52 AM, Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>>
> >>> On 29 July 2016 at 15:26, Robinson, Paul via llvm-dev
> >>> <llvm-dev at lists.llvm.org> wrote:
> >>>> I believe David Chisnall up-thread cited a difference in
checkout
> times
> >>>> on the order of a handful of seconds versus a couple of
minutes.
> While
> >>>> naively it might seem not a big deal, over time and
depending on what
> you
> >>>> are trying to do yes it can be a big burden.
> >>>
> >>> TL;DR: This thread is dead. Let's move on.
> >>>
> >>> I think the biggest fallacy in this thread is that changing
process is
> cheap.
> >>>
> >>> It is certainly cheap for me to do "git foo" instead
of "git bar" from
> >>> now on. It's moderately expensive to change my buildbot
> >>> configurations, Zorg's builders and re-test everything for
public CI.
> >>> It's a lot more expensive to change how distributions
build their
> >>> hundreds of thousands of packages over multiple LTS releases,
or how
> >>> downstream users like Sony, Apple or ARM re-factor their
entire build
> >>> systems (which very likely link to a lot of non-LLVM stuff),
and then
> >>> some.
> >>>
> >>> None of that is impossible, most of that is a "one
off". Most of the
> >>> companies and big projects "could" afford to do
that.
> >>>
> >>> But there are two big points that people like me, Paul and
David have
> >>> been unsuccessfully trying to make obvious:
> >>>
> >>> 1. Not every LLVM user is as big as FreeBSD, Sony or Apple.
There are
> >>> a lot of very interesting projects (hobbyists, academia,
professional)
> >>> using Clang, LLVM, libc++, etc. that don't have the staff
to do that
> >>> move. Being a hobbyist myself, I know too well that, when a
library
> >>> radically changes the way they behave (like boost did every
new
> >>> release about 10 years ago), I will stop using it.
> >>>
> >>> 2. Changes in complex systems have unwanted larger
consequences. Build
> >>> systems are some of the most complex systems in existence
because
> >>> they're mostly irrational and patched together with duct
tape and
> >>> paper clips. What may be very simple for some build systems,
could be
> >>> impossible for others, and that's not the other's
team's fault.
> >>>
> >>> So, if you have a complex build system yourself, and you spent
some
> >>> time and have figured out that it would be easy, you *cannot*
assume
> >>> it should be easy for everyone with an less or equally complex
build
> >>> systems.
> >>>
> >>> If you find it simple to change your own workflow towards this
or that
> >>> solution, you *cannot* assume everyone else should feel the
same. This
> >>> also doesn't diminish their intelligence or competence.
Intelligent
> >>> and competent people work in very different ways, and it's
actually
> >>> because of that fact that we can do such complex software
works in a
> >>> multitude of systems. If we were all equal, we wouldn't
need to
> >>> discuss anything. :)
> >>>
> >>> Mehdi said very early, and repeated many time, on some of the
threads,
> >>> something to the effect of: "Saying how hard or easy it
is for you is
> >>> an invalid argument, we need more concrete facts".
> >>>
> >>> I absolutely agree with that statement, but interpreting how
easy or
> >>> hard concrete facts would be fall on the same fallacy, so it
doesn't
> >>> bring us closer to consensus, it brings us closer to dissent.
> >>>
> >>> That is why I think this thread has already surpassed it's
usefulness
> >>> (for a long time), and we need a concrete write up on the
proposal. (I
> >>> hear it's in progress, let's wait for it).
> >>>
> >>> From now on, I'd propose the discussion to be *just* about
this
> >>> specific proposal, preferably over a Phabricator review on the
> >>> document. People that have strong opinions about it should
wait for
> >>> the survey.
> >>>
> >>> Just to reiterate, the survey is to collect opinions in a
formal and
> >>> non-passionate manner. It will not be a "majority
vote", and we're not
> >>> locked between these two solutions as they're absolutely
drawn out in
> >>> the documents, nor we are forced to take any decision if the
community
> >>> is clearly split. The last think I want is to destroy part of
the
> >>> community while trying to make it better.
> >>>
> >>> But this long thread is not doing any good either.
> >>>
> >>> cheers,
> >>> --renato
> >>> _______________________________________________
> >>> 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/20160730/19319787/attachment.html>