<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 21, 2020, 1:57 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 21, 2020 at 12:24 PM Stellar Accident via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">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">Thanks Chris. As the "former colleague" my +1 is a bit implied :)<div><br></div><div>I took the liberty of drafting an actual proposal doc: <a href="https://github.com/stellaraccident/llvm-www/blob/master/proposals/LP0002-LLVMIncubator.md" target="_blank" rel="noreferrer">https://github.com/stellaraccident/llvm-www/blob/master/proposals/LP0002-LLVMIncubator.md</a></div><div><br></div><div>>From a process perspective, I'm not entirely clear on the next steps here (and this is the first proposal after the proposal to have a proposal process -- so I guess we're dogfooding it). In my mind, even though there seems to be consensus on this RFC thread to move forward, this seems like a large enough change that we should commit a proposal to memorialize it (I imagine we're going to revise it over the years, and the history will be useful). Should I create a separate "PITCH" thread or just commit a version of the above proposal for further revision? I'm also happy to send it out for an actual review but have actually never made changes to the llvm-www repo and don't know how we review such things.</div></div></blockquote><div><br></div><div>My understanding of the proposed process is that the proposal/PITCH process is only happening on controversial RFCs:</div><div><br></div><div>> If it can be resolved through normal means, great - no need for additional process. We expect this to continue to be the common case. If a discussion turns controversial, escalate the RFC into a "proposal pitch", to help frame both sides of the discussion. </div><div><br></div><div>The current RFC thread does not seem to have reached this point.<br></div></div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Sg - wasn't looking to add process, but it was suggested OT that if I had the time, it might be useful to write a proposal doc. And then that is where I found the (new) proposal process.</div><div dir="auto"><br></div><div dir="auto">It seems like the proposal process was created primarily for formalizing decision making for controversial items. Is it possible that it can/should also be used to memorialize "significant" policy decisions (even if not controversial)?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><div>-- </div><div>Mehdi</div><div><br></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><br></div><div>Happy to do whatever to move this forward!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 20, 2020 at 3:43 PM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">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>Hi all,<div><br></div><div>Today, we maintain a high bar for getting a new subproject into LLVM: first a subproject has to be built far enough along to “prove its worth” to be part of the LLVM monorepo (e.g. demonstrate community, etc). Once conceptually approved, it needs to follow all of the policies and practices expected by an LLVM subproject.</div><div><br></div><div>This is problematic for a couple reasons: it implicitly means that projects have to start *somewhere else* but proactively decide to follow LLVM design methodology and principles in the hope of being accepted. It is sometimes socially difficult to get these projects going because there are many other forces that could encourage other practices. For example, I personally encountered this at Google with MLIR - “why aren’t you using Google coding standards?”, several of us are currently discussing this in a new skunkworks project in the “compilers for hardware” world, and the Flang and other projects have found this challenging in the past. Once the project gets to a point of critical mass with the “wrong” approach, it is very difficult and expensive to convert to the LLVM style, and from a social perspective, inertia sometimes leads to forking off to separate projects instead of folding back in to LLVM.</div><div><br></div><div>A former colleague recently suggested the idea of introducing an incubator process of some sort (e.g. xref the <a href="https://incubator.apache.org/" target="_blank" rel="noreferrer">Apache version of this idea</a>). I think this is a really interesting idea, and it is much easier now that the majority of the “official” code is in the LLVM monorepo.</div><div><br></div><div>Here is a sketch of how this could work:</div><div><br></div><div> - We maintain the same high bar to get into the LLVM monorepo, LLVM CI etc. No change here.</div><div><br></div><div> - We have a very light-weight proposal process that allows people to create incubator projects in the LLVM organization, with no code up front. The project would be required to have e.g. a charter document and README.</div><div><br></div><div> - Such projects are required to follow the LLVM developer policy, coding standards, CoC, etc, but can define their own stability and evolution process, code owners, etc.</div><div><br></div><div> - When the project is ready to graduate, it would follow the existing process for becoming a first-class part of the mono repo.</div><div><br></div><div> - We have some policy on when to retire/delete projects, which can be ironed out the first time it comes up (e.g. start with a nomination).</div><div><br></div><div> - We could even try to help encourage new projects to include a ‘mentor’ that has experience with the LLVM project to help nudge things in the right direction and encourage proper development approach.</div><div><br></div><div>What do you think? Is anyone interested in helping to write up a more detailed proposal?</div><div><br></div><div>-Chris</div><div><br></div><div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div>
</blockquote></div></div></div>