<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 9:12 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><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">On 12 May 2016 at 17:07, Daniel Berlin via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> In my talks with a number of these projects, they pretty much don't care<br>
> what anyone else does, and plan to stick to their own import/etc schedules<br>
> no matter what LLVM does with stable releases :)<br>
<br>
</span>Is there anything we can do to make they care?<br></blockquote><div><br></div><div>For all of them? Unequivocally: no.</div><div>You can define a subset of external customers you care about, and want to work with you, and do something for them.</div><div><br></div><div>Whether you can get a subset that is large enough to reduce costs/burden for you/distro folks is an unknown :)</div><div><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"><br>
What I heard from them is that the upstream process wasn't clear<br>
enough with regards to fixes, API stability and process (which were<br>
pretty much echoed in this thread).<br>
<br>
Maybe, if we fix most of those problems, they would care more?<br></blockquote><div><br></div><div>Maybe.  In any case, LLVM (as a community) has to  define who the customers are that it wants to prioritize, and know what they care about, before you can start solving their problems. :)</div><div><br></div><div>IE you need an actual ordered hierarchy of who llvm, as a community, cares about supporting.  </div><div>Without this, you can't possibly define the effort you should go to to actually support them, and what problems you should and should not solve.g</div><div><br></div><div>And the answer can't be "everyone", because you have sets of customers whose priorities and desires are often at odds with others.</div><div><br></div><div>(For example, "people trying to get high performance at all costs from LLVM" may have a diametrically opposed set of desires from "people trying to ship production LLVM based compilers")<br><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"><span class=""><br>
> (For reference, Google *ships* the equivalent of about 13-16 linux<br>
> distributions in products, uses about 5-6x that internally, and we have a<br>
> single monolithic source repository for the most part.  I have the joy of<br>
> owning the third party software policies/etc for it, and so  end up<br>
> responsible for trying to deal with maintaining single versions of llvm for<br>
> tens to hundreds of packages).<br>
<br>
</span>You sound like the perfect guy to describe a better upstream policy to<br>
please more users.<br></blockquote><div>The problem is you may not like my policies ;)</div><div>At some point, at scale, you have to assign who bears the burden of various support-like things.</div><div><br></div><div>We already do this a little bit in the community, telling people they need to update tests for what their patches break, etc.</div><div><br></div><div>This is not unlike that, just at a larger scale. So, for example, saying who bears the cost of API compatibility, and to what degree.</div><div><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"><br>
But I don't want to volunteer yourself. :)<br>
<span class=""><font color="#888888"><br>
--renato<br>
</font></span></blockquote></div><br></div></div>