<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 25, 2016, at 5:54 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jul 25, 2016 at 5:47 PM Mehdi Amini 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On Jul 25, 2016, at 4:18 PM, Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
> 6. The target's code must have been adapted to the developers policy as well as<br class="">
> the coding standards. This can take a while and it should be fine to<br class="">
> accept external code into LLVM as experimental, but not officially.<br class="">
<br class="">
FWIW I’m not fond of not having this as the experimental part in the first place.<br class="">
It is harder to have things moving after being upstreamed.<br class="">
I’d expect the upstreaming of a backend (into experimental state) to be piece by piece with proper code review according to the current project standard.<br class=""></blockquote><div class=""><br class=""></div><div class="">I'm not sure it makes sense to insist on backends being incrementally developed in the open. While I rather prefer that (WebAssembly has been fun to watch here), it doesn't seem realistic.</div><div class=""><br class="">Every backend I can think of other than WebAssembly and the original AArch64 port has come into existence out of tree, and only after proving useful to some folks decided to move into the tree. I'd personally advocate for keeping that door open.</div></div></div></div></blockquote><div><br class=""></div><div>There is a nuance: the fact that it is not developed in tree does not prevent from splitting it in “some” pieces that can be independently reviewed, this is what we (should) do for any large chunk of code that we integrate.</div><div>Now it is possible that considering the current way of implementing backend in LLVM, there is not much pieces that can be split out of a backend (I still think that’s unfortunate though).</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">All that said,I completely agree regarding coding conventions and other basic stuff. I don't think we need to wait for the official point in time to insist on all of the fundamental coding standards and such being followed.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
><br class="">
> A soft(-er?) requirement:<br class="">
><br class="">
> 7. The test coverage is broad and well written (small tests, documented). Where<br class="">
> applicable, both the ``check-all`` and ``test-suite`` must pass in at least<br class="">
> one configuration (publicly demonstrated, ex. via buildbots).<br class="">
<br class="">
Same as before: this is a no-brainer should be applicable with any patch, even in experimental state: small and documented lit tests.<br class=""></blockquote><div class=""><br class=""></div><div class="">Yep, this seems like it should always be true regardless of the experimental nature.</div></div></div>
</div></blockquote></div><br class=""></body></html>