<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 5, 2020 at 10:15 AM Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sat, 5 Dec 2020 at 05:48, Eric Christopher via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">No. I meant every word that I said. The policy encoded existing practice and exactly how we've handled things for years. I'm sorry if this hasn't matched your experiences, as I said, but there's nothing new or radical with what we wrote down. It's what we've intended and how we've meant to act.<br></div></div></blockquote><div><br></div><div>Precisely.</div><div><br></div><div>I'm not taking personally the statement that "[the policy's] only purpose is to provide cover for the existing fact". I have no reason to provide cover for Bazel, Geoffrey or Google. I didn't mean to create precedent for anything and just wanted to make sure we discuss the technical details with the background of how we decide things covered in a policy that would only describe what we've done in the past.</div><div><br></div><div>I also don't think the inclusion of GN is prior-art. It had a lot less scrutiny than the current discussion and it has been largely ignored (because nothing wrong happened so far). There are lots of little things like that in LLVM that go unnoticed, it's really hard to control such a large project without adding unreasonable constraints to the development process.</div></div></div></blockquote><div><br></div><div><span style="color:rgb(0,0,0)">It isn't clear to me what makes you say that? You may not have been involved with it and you may haven't been paying attention at the time, but it seems unfair to claim that it didn't have scrutiny or it went in without the </span><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">usual </span></font><span style="color:rgb(0,0,0)">proper consideration.</span></div><div><div style="color:rgb(0,0,0)">In particular it has been discussed on llvm-dev@ like any other proposal, and the thread was pretty long: <a href="http://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html">http://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html</a> ; it also went further with a lightning talk **and** a round-table during a llvm dev meeting.</div><div style="color:rgb(0,0,0)"><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>It's exactly because this discussion is again moving into personal remarks and making use of "facts" and policies that I'm sure this won't go anywhere, again. And this is why I support Tom's idea to turn this into a pitch: there are no personal opinions on the document, just facts and solutions to problems.</div></div></div></blockquote><div><br></div><div>I'll repeat myself but: escalating an RFC into a  “LLVM Proposal Process” requires being able to "describe the controversy" and summarize both sides of the discussion. I don't see how this is possible without having the objections being restated.</div><div>So far Chris withdrawn his objection in light of the policy you drove: "Since this is being added within the bounds of a now-existing policy, I will withdraw my objections".</div><div>Stefan reiterated his objection, but I read it as in bound for the policy rather than really about this proposal (I may be wrong, that's just how I understand it).</div><div><br></div><div>Another issue I see with escalating, is that while the “LLVM Proposal Process” seems like a way to unblock deadlocks, it isn't clear to me that it is the best way to find tradeoff and compromise that can be reached through discussions.</div><div>For example there are very good technical questions raised by Tom in the bullet points in the second part of this email: <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-November/146671.html">http://lists.llvm.org/pipermail/llvm-dev/2020-November/146671.html</a> ; I'm afraid that these wouldn't be addressed the same way if we just moved on with a more formal decision process. I don't understand why we shouldn't make a genuine effort to address the practical aspects here?</div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div>