<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: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:0cm;
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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">> > On Fri, Jul 22, 2016 at 3:40 PM, Daniel Sanders via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">> > Do you have an example in mind? I'd expect them to rely on each 'master' being<br>
> > an improvement on 'master^'. I wouldn't expect them to be interested in how<br>
> > 'master^' became 'master'.<o:p></o:p></p>
<p class="MsoNormal">><o:p> </o:p></p>
<p class="MsoNormal">> I would love it if each master commit was an improvement on the previous commit, or at last<o:p></o:p></p>
<p class="MsoNormal">> was virtually guaranteed to be not broken. It's most annoying that the existing LLVM history<o:p></o:p></p>
<p class="MsoNormal">> has a lot of examples of commits being reversed by a later commit.<o:p></o:p></p>
<p class="MsoNormal">><o:p> </o:p></p>
<p class="MsoNormal">> The ease in git of branching -- and more importantly rebasing the branch on a later state of master<o:p></o:p></p>
<p class="MsoNormal">> -- means that you can run buildbots for all the different platforms on each pull request BEFORE<o:p></o:p></p>
<p class="MsoNormal">> merging it to master.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I'd like to see this too. I'd prefer not to make it a requirement for _<i>all</i>_ buildbots to pass before commit though. I'm thinking that we could make passing 'fast'
buildbots mandatory before commit but leave 'slow' buildbots in the current post-commit testing scheme. That way targets that can provide fast buildbots will win additional stability guarantees but the community isn't held back by the slowest buildbot. We'd
have to discuss where we'd draw the line between 'fast' and 'slow'.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> bruce.hoult@gmail.com [mailto:bruce.hoult@gmail.com]
<b>On Behalf Of </b>Bruce Hoult<br>
<b>Sent:</b> 22 July 2016 14:33<br>
<b>To:</b> Daniel Sanders<br>
<b>Cc:</b> Renato Golin; LLVM Developers<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>
<div>
<div>
<div>
<p class="MsoNormal">On Fri, Jul 22, 2016 at 3:40 PM, Daniel Sanders via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Do you have an example in mind? I'd expect them to rely on each 'master' being<br>
an improvement on 'master^'. I wouldn't expect them to be interested in how<br>
'master^' became 'master'.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I would love it if each master commit was an improvement on the previous commit, or at last was virtually guaranteed to be not broken. It's most annoying that the existing LLVM history has a lot of examples of commits being reversed by
a later commit.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The ease in git of branching -- and more importantly rebasing the branch on a later state of master -- means that you can run buildbots for all the different platforms on each pull request BEFORE merging it to master.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If buildbots are not fast enough to test every change (let alone repeatedly) then you can keep a pristine "master" head and a "proposed master" head that might have several pull requests added onto it sequentially. Then have the buildbots
test the "proposed master" and if it passes then fast-forward advance the "master" head to the current "proposed master" head. Then merge the next batch of pull requests onto "proposed master", rinse and repeat.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If a "proposed master" fails and it has more than one pull request in it, then you can bisect it to find the bad pull request, throw it out, and try again without it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>