llvm dev - May 2017 - Add more projects into Git monorepo

On 9 May 2017, at 16:59, Mehdi AMINI <joker.eph at gmail.com>
wrote:
> 
> I'm not sure if you really read the last sentence of what I wrote, or
if you followed the previous discussions on the plan here?
> At this point I believe that this concern is non-existent per the read-only
individual repo.
The read-only repo is only useful if you don’t intend to contribute stuff back
upstream.  There is no convenient workflow for cloning libunwind / libc++ /
libwhatever, hacking on it, and sending pull requests.
> We can leave it there :)
> There have been extensive discussions, a BoF, and documentations, please
refer you to these first (granted we haven't really talked about libunwind,
but I'm not sure many people will be strongly opposed to libunwind having
its separate life).
There have been multiple discussions, and the conclusion from all that I have
participated in was that projects that are tightly version locked to LLVM should
be in the monorepo, everything else should be separate.  Apparently there is now
a plan underway to not do this and to make life harder for people who work on
the projects that are not version locked to LLVM.

I am simply repeating the objections that numerous people have made in each of
these discussions.

David

2017-05-09 9:03 GMT-07:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:
> On 9 May 2017, at 16:59, Mehdi AMINI <joker.eph at gmail.com> wrote:
> >
> > I'm not sure if you really read the last sentence of what I wrote,
or if
> you followed the previous discussions on the plan here?
> > At this point I believe that this concern is non-existent per the
> read-only individual repo.
>
> The read-only repo is only useful if you don’t intend to contribute stuff
> back upstream.

Your point was about CI...
(unless you're working on some CI that would fix bugs and send PR?)

> There is no convenient workflow for cloning libunwind / libc++ /
> libwhatever, hacking on it, and sending pull requests.
>
We considered git-svn for this though.


>
> > We can leave it there :)
> > There have been extensive discussions, a BoF, and documentations,
please
> refer you to these first (granted we haven't really talked about
libunwind,
> but I'm not sure many people will be strongly opposed to libunwind
having
> its separate life).
>
> There have been multiple discussions, and the conclusion from all that I
> have participated in was that projects that are tightly version locked to
> LLVM should be in the monorepo, everything else should be separate.
> Apparently there is now a plan underway to not do this and to make life
> harder for people who work on the projects that are not version locked to
> LLVM.
>
We have a different understanding.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/0dcd4841/attachment.html>

> On May 9, 2017, at 9:06 AM, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> 2017-05-09 9:03 GMT-07:00 David Chisnall <David.Chisnall at cl.cam.ac.uk
<mailto:David.Chisnall at cl.cam.ac.uk>>:
> On 9 May 2017, at 16:59, Mehdi AMINI <joker.eph at gmail.com
<mailto:joker.eph at gmail.com>> wrote:
> >
> > I'm not sure if you really read the last sentence of what I wrote,
or if you followed the previous discussions on the plan here?
> > At this point I believe that this concern is non-existent per the
read-only individual repo.
> 
> The read-only repo is only useful if you don’t intend to contribute stuff
back upstream.
> 
> Your point was about CI...
> (unless you're working on some CI that would fix bugs and send PR?)
>  
> There is no convenient workflow for cloning libunwind / libc++ /
libwhatever, hacking on it, and sending pull requests.
> 
> We considered git-svn for this though.
> 
>  
> 
> > We can leave it there :)
> > There have been extensive discussions, a BoF, and documentations,
please refer you to these first (granted we haven't really talked about
libunwind, but I'm not sure many people will be strongly opposed to
libunwind having its separate life).
> 
> There have been multiple discussions, and the conclusion from all that I
have participated in was that projects that are tightly version locked to LLVM
should be in the monorepo, everything else should be separate.  Apparently there
is now a plan underway to not do this and to make life harder for people who
work on the projects that are not version locked to LLVM.
> 
> We have a different understanding.
I feel like I need to take a minute here to voice my supreme frustration with
the way this discussion has gone and this small sentence captures it entirely.

From beginning to end these git migration conversations have involved a whole
lot of people talking past each other and a lot of assumptions that are not
shared. Many of us are very much not on the same page. The only thing that we
had a significant consensus on was that we'd like to move to GitHub. Other
than that we have more disagreement than agreement.

We do not have consensus on an all-in-one monorepo, and any notion that we do is
ignoring the significant dissent. There was less disagreement with a mono-repo
that had only tightly coupled projects, but that itself is hard to nail down and
define, and there are still many people (myself included) who prefer the
multi-repo solution.

Mehdi, I don't know if it is your intent, but in many places in this thread
you sound as if this decision has been made and the community is fully
supporting your decision. Please don't do that. It would be nice if as a
community we considered the concerns of our members instead of offhand
dismissing them.

I think we should spend some time discussing and understanding the needs of our
corporate contributors and the needs of the other open source projects that
contribute to, use, and distribute LLVM. I believe that disregarding the
concerns of communities like the BSD and Linux communities would be a severe
detriment to the LLVM project.

-Chris
> 
> -- 
> Mehdi
> 
> _______________________________________________
> 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/20170510/2a525423/attachment-0001.html>