[llvm-dev] Add more projects into Git monorepo

Wed May 10 20:35:55 PDT 2017

Hi Chris,

2017-05-10 19:21 GMT-07:00 Chris Bieneman <beanz at apple.com>:

>
> 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>:
>
>> 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.
>
>
> 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.
>
>
You'll have to elaborate what is wrong with this sentence, because I'm
basically saying that I disagree there was a consensus or a conclusion on
what goes exactly in the monorepo, which is what David was claiming. I
believe the exact set of projects was punted to future discussions.

I also happen to know that some important stakeholders are strongly against
not having the full toolchain together (i.e. libc++ has to be with clang
for example) and would strongly prefer status quo (and staying on SVN) to
having half of the toolchain together but not as a whole (not that they
necessarily have to have their way, but that's another important weight in
the balance).

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

Sure.

> We do not have consensus on an all-in-one monorepo,
>

Yes. But:
1) We don't have a consensus on anything but "we should go to GitHub" at
this point.
2) Please acknowledge that the opposite is true as well (which is what my
sentence above what answering to!).

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

This is your reading, this is not what I wrote. Please don't
over-interpret. See at the end of this email for a reminder on where I
stand right now.

> It would be nice if as a community we considered the concerns of our
> members instead of offhand dismissing them.
>

The only thing I dismiss is what is not supported by any facts:

Example from this thread: "the CI for libunwind will have to checkout extra
stuff" -> "individual repositories are addressing this". Unless I have new
extra informations that I can take into account about why the individual
repo are not addressing this specific exact concern, yes you can consider
that I'm dismissive this "concern".
Also, not that expressing a disagreement with your opinion is not the same
thing as dismissing it though, so please don't put everything in the same
bucket. If you have any issue, let's be specific.

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

At this point, I believe I spent a considerable amount of time
discussing/experimenting/prototype/considering scenarios/etc. I don't mean
this to say that I have all the knowledge of all the possible situations,
or that my personal opinion would matter more, but I somehow feel that your
paragraph above is negating the time and energy I made into accumulating
all the elements and engaging in discussions with all possible parties
interested into it.

As a reminder, the current status today and my position is the same as in
January: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109015.html
; which can be summarized as: "At some point, if the experiment is
conclusive, we should be able to build a larger majority and hopefully
reach a consensus that the proposed prototype can be considered viable for
development and start planning the actual committing changes."
There's a lot of uncertainty there, I never announced any "decision" (which
I never pretended to be in my hands).

See also Chris' answer for a more explicit version:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109115.html

Best,

--
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170510/9d283ae6/attachment.html>