<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">I don’t know what you mean by dealing with the merging, I don’t expect any<br>
difficulties, you need to elaborate.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">What I don’t see you addressing here is why this should be more of a problem in the monorepo case (as it was implied in the email I was answering to).<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Your answer made it sound like you thought the monorepo would solve all downstream problems ("I don't know what you mean… I don't expect any difficulties"),
 which it clearly does not.  Sorry for the misunderstanding.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> mehdi.amini@apple.com [mailto:mehdi.amini@apple.com]
<br>
<b>Sent:</b> Friday, July 29, 2016 11:17 AM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> David Chisnall; Bruce Hoult; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] One or many git repositories?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jul 29, 2016, at 11:07 AM, Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">-----Original Message-----<br>
From: llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org">mailto:llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Mehdi<br>
Amini via llvm-dev<br>
Sent: Friday, July 29, 2016 10:02 AM<br>
To: David Chisnall<br>
Cc:<span class="apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>; Bruce Hoult<br>
Subject: Re: [llvm-dev] [RFC] One or many git repositories?<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Jul 29, 2016, at 2:19 AM, David Chisnall<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><<a href="mailto:david.chisnall@cl.cam.ac.uk">david.chisnall@cl.cam.ac.uk</a>> wrote:<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><a href="mailto:dev@lists.llvm.org">dev@lists.llvm.org</a>> wrote:<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
What I meant by “different problem" is that “downstream users” for<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">instance don’t need to commit, that makes their problem/workflow quite<br>
different from an upstream developer (for instance it is fairly easy to<br>
maintain a read-only view of the existing individual git repo currently on<br>
<a href="http://llvm.org">llvm.org</a>).<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
I’m not convinced by this distinction.  A lot of downstream developers<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">need to patch LLVM and we benefit when they upstream their changes.<br>
<br>
I made a difference between downstream users and developers. I.e. someone<br>
that just need to get and build compiler-rt vs someone that want to<br>
*commit* to LLVM. Note that even by getting a single repo you can still<br>
send a patch to the mailing list and someone can commit it for you<br>
(including correct author attribution contrary to SVN).<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">We should not make it harder for them to do this.  To give a couple of<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">example downstream projects, both FreeBSD and Swift have patches on LLVM /<br>
Clang in their versions that they gradually filter upstream.  Both<br>
projects have LLVM committers among their members.  If the workflow that<br>
we recommend for them makes upstreaming easy then they benefit<br>
(maintaining a fork is effort) and LLVM benefits (having people provide<br>
bug fixes makes our code better).<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
The workflow that we want to recommend to these people is:<br>
<br>
- Fork the repo that you’re interested in from the LLVM GitHub<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">organisation<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">- Make your changes<br>
- Send pull requests for anything that you think is of interest to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">upstream<br>
<br>
<br>
Note that the workflow you describe above still requires to export their<br>
patch and import it in this clone before pushing.<br>
(Note also that we accept patches on the mailing list, so one does not<br>
even need to clone the official repo).<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">This makes the barrier to entry for sending code back upstream *much*<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">lower than it currently is,<br>
<br>
I don’t understand this statement. As of today you can send a diff to the<br>
mailing list, I don’t see how lower the bar can be.<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">to the benefit of all.  If the alternative is:<br>
<br>
- Fork a read-only repo that you’re interested in from the LLVM GitHub<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">organisation<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">- Make your changes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Why? If you know you want to *push* commits upstream, fork the only useful<br>
repo for that in the first place.<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">- Fork a different repo from the LLVM GitHub organisation<br>
- Run a script to filter some of your changes into that one<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
I don’t know why you think there is a need for a script, or why it is<br>
different from today.<br>
Let say I’m working on a fork of the compiler-rt read-only repo and I want<br>
to upstream a patch at some point:<br>
<br>
Today:<br>
<br>
- cd /path/to/compiler_rt-forked<br>
- git format-patch …<br>
- cd /path/to/compiler_rt-upstream<br>
- git am  /path/to/compiler_rt-forked/0001-My-awesome-changes.patch<br>
- git svn dcommit<br>
- done<br>
<br>
Tomorrow with a monorepo:<br>
<br>
- cd /path/to/compiler_rt-forked<br>
- git format-patch …<br>
- cd /path/to/unifiedrepo-upstream<br>
- git am  /path/to/compiler_rt-forked/0001-My-awesome-changes.patch —<br>
directory=compiler-rt<br>
- git push<br>
- done<br>
<br>
Alternatively, if I’m upstream a patch once a year, I don’t really need to<br>
push it myself.<br>
<br>
- cd /path/to/compiler_rt-forked<br>
- git format-patch …<br>
- email the patch.<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">- Send a pull request from that<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Note that I think we deferred any change to the workflow for future<br>
discussions (pull-request are not part of our workflow today).<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">- Deal with merging between the two yourself<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
I don’t know what you mean by dealing with the merging, I don’t expect any<br>
difficulties, you need to elaborate.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Almost no upstream patch survives contact with the reviewers unscathed<br>
(and quite often it doesn't look exactly like your local patch anyway,<br>
for reasons ranging from expediency to local coding standards).<br>
Therefore the patch that you merge back in to your local repo from<span class="apple-converted-space"> </span><br>
upstream differs from the one you already have locally.  If you are *very*<br>
lucky, the differences can be handled with accept-theirs; in my experience<br>
this is not normal, and in many cases you need to manually revert your<br>
original local patch before merging the patch as received from upstream.</span><o:p></o:p></p>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">That's what "dealing with merging" means.  I invite you to review<br>
"Living Downstream Without Drowning" if you still don't understand;</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Don’t worry, I’m living downstream, and perfectly aware of the situation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(And I was in the room at the dev meeting).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">it describes a number of tactics we've developed over the years to<br>
try to simplify the dealing-with-merging problem.<br>
<br>
I had two entire dev-meeting sessions full of people who seemed to be<br>
having this problem.  Maybe you don't; if so, you're lucky, but it<br>
doesn't mean the problem fails to exist.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The “problem” exists, it exists today, and it will tomorrow whatever solution we go with (monorepo or split ones).<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What I don’t see you addressing here is why this should be more of a problem in the monorepo case (as it was implied in the email I was answering to).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">— <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Mehdi<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">--paulr<br>
<br style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
I strongly suspect that we’ll get a lot fewer useful contributions from<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">downstream.  Or downstream people will just work on the monorepo and eat<br>
the cost.<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
If someone is working on a downstream LLVM project and becoming familiar<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">with our codebase, then we want them to be subtly nudging their workflow<br>
so that they eventually become LLVM contributors without noticing!<br>
<br>
Sure. The distinction between “downstream users” and “developers” was made<br>
in response to “there exists many user that just download and build a<br>
subproject”. These are not people that are *developing* on a downstream<br>
fork.<br>
<br>
—<br>
Mehdi<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>