[llvm-dev] Add more projects into Git monorepo

Justin Lebar via llvm-dev llvm-dev at lists.llvm.org
Fri May 12 12:55:06 PDT 2017


Thank you for doing this, Takumi.  Many of us who choose to use your
unofficial monorepo find it invaluable, and adding these additional
repos will be a big help.

-Justin

On Thu, May 11, 2017 at 11:45 AM, Zachary Turner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Personally, I don't think it is even possible to please everyone.  While I
> don't want to ignore the dissent, I also don't want to ignore the fact that
> the dissent *has* been a minority, and I believe there has been more dissent
> in *not* adopting monorepo as there has been to adopting monorepo.
>
> Somewhere along the line, someone has to pull the trigger and make a
> decision.  There are people who are just as inconvenienced today (which,
> btw, has been a lingering inconvenience for many years in some cases) by
> *not* having a mono-repo as others would be by having a mono-repo.
>
> Discussions are only meaningful insofar as they contribute something new to
> the playing field.  We have had so many discussions, surveys, talks, email
> threads, experiments, etc that at this point I honestly don't know how else
> to meaningfully contribute something new?
>
> On Wed, May 10, 2017 at 8:36 PM Mehdi AMINI via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> 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
>


More information about the llvm-dev mailing list