<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I don’t think there is any negative connotation to escalating to the proposal process. We should do this more often to make progress on things like this.<div class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 9, 2020, at 8:45 AM, Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Stella,<div class=""><br class=""></div><div class="">I don't understand why this would be a deadlock here: the thread has been mostly centered around the fact of "having a pitch or not having a pitch", as well as a meta-point covered in the policy. Escalating to the “LLVM Proposal Process” (pitch) for these reasons sets a really bad precedent in my opinion. If you move into the “LLVM Proposal Process”, I'll insist that the pitch is clearly centered about the merits and technicality of this proposal itself and <b class="">not</b> about the meta-point that is explicitly covered by the policy. We shouldn't have to revisit the entire policy every time there is any addition to the project.</div><div class=""><br class=""></div><div class="">-- </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 8, 2020 at 11:21 PM Stella Laurenzo via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></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" class=""><div class="">+1 to making this a pitch - This thread seems deadlocked to me (with plenty of evidence that everyone is acting in what they see is in the best interests of the community and having a legitimate disagreement). In my experience, as well, when a discussion gets to this phase and there is still a strong objection by one or two parties still willing to make it (which can be exhausting to hold such lines), there are almost always more people who share the viewpoint but don't want to get involved. Best to follow a real process towards resolution when things get to that level. I dislike discussions of attrition and would welcome a process for resolving this one. We feel uncomfortably close to attempting to "get this through on a technicality" (full disclosure: I would benefit from such an outcome), and I don't think that would be a success -- it is alienating. We've got a process for deciding such things. Let's use it and then live with the outcome.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 8, 2020 at 4:01 PM Geoffrey Martin-Noble via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></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" class="">Thanks everyone. I will move forward with a pitch as part of the proposal process.<div class=""><br class=""></div><div class="">The reason I reopened this as an RFC was because I thought the more general questions should have been resolved as part of the discussion in Renato's support policy RFC and that therefore this would not necessarily be controversial to the point we couldn't resolve it as part of an RFC. (In particular, some people said their objections were resolved by the existence of an explicit policy). Apologies that that took this thread in a direction that lost focus.</div><div class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 8, 2020 at 12:40 PM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:<br class=""></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" class=""><a class="gmail_plusreply" id="gmail-m_5392852670366416414gmail-m_739134285752227805gmail-m_-7123897784371506159m_8583704625479458863plusReplyChip-0" href="mailto:gcmn@google.com" target="_blank">+Geoffrey Martin-Noble</a> and <a class="gmail_plusreply" id="gmail-m_5392852670366416414gmail-m_739134285752227805gmail-m_-7123897784371506159m_8583704625479458863plusReplyChip-1" href="mailto:tstellar@redhat.com" target="_blank">+Tom Stellard</a> <div class=""><br class=""></div><div class="">In my effort to smooth the process out here I spoke with Tom offline and we've agreed that a pitch proposal seems to be the best way forward. From our discussion I believe that he disagrees with adding unsupported build systems to llvm and what methodology we should use to determine their or similar multiple versions of functionality inclusion (please do correct me if I'm wrong here). I think it makes sense to limit the discussion in the pitch to adding unsupported build systems.</div><div class=""><br class=""></div><div class="">My personal take on this and why I've been helping shepherd this along: <br class=""><br class="">I believe that we should be enabling other people to do work in llvm as long as </div><div class=""><br class=""></div><div class=""> a) it doesn't impact maintainability of the core system (open to debate in some ways), </div><div class=""> b) they have a history/desire to be responsible maintainers, and </div><div class=""> c) it's easy enough to remove if it becomes an issue.<br class=""></div><div class=""><br class=""></div><div class="">and that doing this helps llvm be used more easily in other projects; thus helping see it's inclusion in more projects, a goal of the project as a whole.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">-eric</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 6, 2020 at 7:07 AM Renato Golin <<a href="mailto:rengolin@gmail.com" target="_blank" class="">rengolin@gmail.com</a>> wrote:<br class=""></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" class=""><div dir="ltr" class="">On Sun, 6 Dec 2020 at 04:38, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank" class="">joker.eph@gmail.com</a>> wrote:<br class=""></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" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><span style="" class="">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 class="">usual </font><span style="" class="">proper consideration.</span><br class=""></div><div class="gmail_quote"><div class=""><div style="" class="">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" target="_blank" class="">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></div></div></div></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Sorry, scrutiny was the wrong word. I meant "trouble". This proposal seems to be having a lot of trouble that GN should have had too. The biggest push back is about adding new build systems, not Bazel versus GN versus CMake.</div><div class=""><br class=""></div><div class="">There seems to be a conflict here about adding a secondary build system. The first could be always thought of as an exception, but the second looks very much like a pattern. The way I see it, from one side there's people worried about maintenance and proliferation of code that is not directly related to the LLVM project (like build systems, editor files, etc) and from the other side, there's people saying this has been happening for a long time.</div><div class=""><br class=""></div><div class="">I tried to solve that by starting the support policy, but not with the intent to validate the inclusion of GN/Bazel, just to help the discussion move to a consensus. I regret having written GN and Bazel by name, which only now I realise they could be used as leverage for one side of the discussion. It was not my intention, and I don't think we should ignore the issues just because GN has been included already, either.</div><div class=""><br class=""></div><div class="">My support for moving this to a document (not necessarily a proposal) is because for most of the original discussion around Bazel, throughout the discussion about the support policy and now the retake on Bazel's inclusions, Tom's points haven't been addressed completely. There seems to be more discussion around semantics, history and precedence than the actual technical details. I'm guilty of that, too, while trying to solve the conflict, and I apologise if the support policy has created more confusion than it solved.</div><div class=""><br class=""></div><div class="">I think laying out the issues in a document and discussing the technical aspects over it would make things easier, not harder. If the support policy needs to be amended to clarify that, so be it. We need to document what happens and what we want to happen, not fix some version of the past as a golden standard for the future.</div><div class=""><br class=""></div><div class="">But as I always say: whatever works. If you want to continue discussing in this thread, by all means, do go on.</div><div class=""><br class=""></div><div class="">cheers,</div><div class="">--renato</div></div></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>