<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@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" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">The <a href="https://llvm.org/devmtg/2015-10/#tutorial4">Living Downstream Without Drowning</a> talk from the 2015 US Dev Meeting might be helpful.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At Sony, we used to merge from upstream once every 6 months; this would cost roughly 3 person-months of effort, due to the extent of our changes (and for many of those merges, I was the person).  We evolved to a continuous-integration model,
 allowing us to apply automation to the problem; last time I added up the numbers, we were averaging roughly one merge conflict or test issue per day, most of which are very low effort to resolve.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Living at the tip of ‘main’ has advantages, the main ones being (a) you get the latest-and-greatest to work with, (b) if your downstream testing finds issues, it’s
<b>much</b> easier to get them resolved right away than it would be six months later.  The main disadvantage, of course, is (c) you get the latest-and-greatest bugs too.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We merge from upstream, rather than rebase.  This was, initially, because we didn’t know any better; however, once we had users outside the immediate team and multiple releases to maintain, it made sense to merge rather than rebase because
 having the combined history on our master branch was consistent with the combined history in our releases.  Bisecting to find the origin of a problem makes it pretty straightforward to determine which releases are potentially affected (or not).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It does make upstreaming patches more, shall we say, interesting.  As it happens, just last week I did a complete diff of our tree with upstream, and we have a couple dozen patches that could be upstreamed; anywhere from typos to significant
 features.  Because we have merged rather than rebased, the need to untangle patch history increases the effort of upstreaming, and so we don’t do it as much as we really ought to.  However, reducing the “surface area” of downstream patches means lower chance
 of merge conflicts, which simplifies merges and makes them less costly; I recommend it highly.  The talk mentioned above has a couple other tips and tricks to try in this area.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So, if you have existing releases/users to support, I think the case is stronger for merging; otherwise, the conventional wisdom is to prefer rebasing.  Certainly rebasing makes it simpler to upstream a patch, and I think also can make
 it easier to track down bugs in your own patches versus upstream behavior (something that we often struggle with).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Good luck with your efforts!<o:p></o:p></p>
<p class="MsoNormal">--paulr<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></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 #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Brian Cain via llvm-dev<br>
<b>Sent:</b> Friday, March 12, 2021 10:27 PM<br>
<b>To:</b> Neil Nelson <nnelson@infowest.com><br>
<b>Cc:</b> LLVM Development List <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] Best practices for rebasing nascent backend?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">If the "pre-merge checks" presentation from recent dev-meeting [1] is to be believed, many revisions proposed for review fail build/tests.   But now that we have those checks, hopefully John's experience for plucking an arbitrary commit
 from main might give better results than in years past.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Another approach might be to review the buildbots to find a commit that is green across the board.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://urldefense.com/v3/__https:/llvm.org/devmtg/2020-09/slides/Goncharov-Pre-merge_checks.pdf__;!!JmoZiZGBv3RvKRSx!pUkgNvkquI9L75LuXFDUaWcmsAHl6rLw8uPPNms7lBd0Zpw2MMNTflmlRLBpu2s8fA$">
https://llvm.org/devmtg/2020-09/slides/Goncharov-Pre-merge_checks.pdf</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Mar 12, 2021 at 9:02 PM Neil Nelson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Not aware that main is broken in many of the test suites. It will be helpful to provide the bugs you find. Or if you can provide a command sequence I can do that here on Ubuntu.</span>
<o:p></o:p></p>
<p><span style="font-size:10.0pt">Perhaps if you give specific detail about the issues you are facing it will allow the other contributors to make suggestions.</span><o:p></o:p></p>
<p><span style="font-size:10.0pt">Neil Nelson</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">On 3/12/21 4:50 PM, John Byrd via llvm-dev wrote:</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Dear llvm, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A few of us are working on a novel LLVM backend in a separate repository, and our new branch uses a lot of the fancy new MLIR stuff.  We'd like the group's opinions as to best practices for keeping in sync with llvm's main branch.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Some of us opine that we should be periodically rebasing our backend on the tip of main.  This has the advantage that we benefit from new main features, but it has the disadvantage that main seems to usually be broken in many of the test
 suites. So it's hard to find a stable commit in main, which passes all the tests on all the buildbots, that we can rebase onto.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">And some of us opine that we should be merging our work with main.  This has the advantage that we never rewrite history, but it also means that it will be painful to squash or rebase our commits, if we ever decide to submit our work upstream.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We've considered doing our work based on one of the release branches, but until recently the development docs recommended against this.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Wisdom would be appreciated; thank you.<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">---<br>
<br>
John Byrd<br>
Gigantic Software<br>
2321 E 4th Street<br>
Suite C #429<br>
Santa Ana, CA  92705-3862<br>
<a href="https://urldefense.com/v3/__http:/www.giganticsoftware.com__;!!JmoZiZGBv3RvKRSx!pUkgNvkquI9L75LuXFDUaWcmsAHl6rLw8uPPNms7lBd0Zpw2MMNTflmlRLApPYlRsQ$" target="_blank">http://www.giganticsoftware.com</a><br>
T: (949) 892-3526 F: (206) 309-0850<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>LLVM Developers mailing list<o:p></o:p></pre>
<pre><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre><a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pUkgNvkquI9L75LuXFDUaWcmsAHl6rLw8uPPNms7lBd0Zpw2MMNTflmlRLD_CPku4A$" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pUkgNvkquI9L75LuXFDUaWcmsAHl6rLw8uPPNms7lBd0Zpw2MMNTflmlRLD_CPku4A$" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">-Brian<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>