<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{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">
<div class="WordSection1">
<p class="MsoNormal">Don’t let <i>Them</i> keep you down. There will always be detractors, but you took concrete action to remove a roadblock to consensus, and I feel that this should be commended. Especially since you did so by writing a bunch of documentation,
and I’m sure you had things you’d rather be doing.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think the policy is pretty good, regardless of the outcome for Bazel.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"> Christopher Tetreault<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> Renato Golin <rengolin@gmail.com> <br>
<b>Sent:</b> Monday, December 7, 2020 10:54 AM<br>
<b>To:</b> Chris Tetreault <ctetreau@quicinc.com><br>
<b>Cc:</b> Mehdi AMINI <joker.eph@gmail.com>; LLVM Dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, 7 Dec 2020 at 18:26, Chris Tetreault <<a href="mailto:ctetreau@quicinc.com">ctetreau@quicinc.com</a>> wrote:<o:p></o:p></p>
</div>
<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>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Renato,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> I feel that adding the support policy was useful. The policy documents expectations, and consequences for non-compliance. This eliminates a whole class of objections that, for
the most part, are no longer being made. Honestly, I feel like the support policy settled most of the technical arguments. It requires that the Bazel build files be supported, that they not impact the rest of the codebase, and documents at what point they
will be removed. I suppose it should go without saying that they should be high quality. All that remains is semantics, history, and precedence.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks Chris! I appreciate the feedback. For a moment there I thought I had made things worse.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><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>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> As for escalating to the LLVM proposal process, it seems to me that we have reached an impasse. Stefan seems to be strongly opposed, and as far as I can tell, so are you. I’m
not in love with the plan either, though I am prepared to accept any outcome of this RFC at this point. I think Stefan’s objection is valid. Just because we have a policy that enumerates the basic requirements for some non-essential thing to be added, and
lists conditions for removal, does not mean that all things that meet the basic requirements should be added. I mean, if “because it meets the basic criteria per the support policy” is enough, then I might as well add an MSBuild project because the one CMake
generates isn’t ideal. I’m sure the MS folks that work with LLVM wouldn’t mind a hand-rolled MSBuild project being in tree. I’m sure Apple would like their hand-rolled XCode project back. Maybe the GHC folks want a Shake based build system? There needs to
be limits.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Open question: has there?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If (there are a sizable part of the community that uses it) and if (they have substantial cost in maintaining it off-tree) and if (the cost of maintaining it in-tree is very low - or it gets kicked out), then (why not?).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To me, the only final question is backports. My answer to that is two-way:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 1. If this is a standard release, the delta is really low and we can pull those files to fix bugs in code that touches it. This will mainly be a problem in build files, not editor configuration or other scripts.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 2. If this is a point release (backports), then we may decide to not backport if it gets muddy. The risk of having a conflict just because of a build file is really really low, and if it does happen, it will be one fix, not all fixes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In both cases, if this keeps happening, and a sizable sub-community gets angry about it, then it breaks the contract and needs to be refactored to not break as often, or be removed. Note that "keeps happening" spanning across releases could
take years.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Tom, does that answer the questions you had?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">--renato<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>