[llvm-dev] LLVM Releases: Upstream vs. Downstream / Distros
Daniel Berlin via llvm-dev
llvm-dev at lists.llvm.org
Thu May 12 13:06:29 PDT 2016
On Thu, May 12, 2016 at 9:12 AM, Renato Golin <renato.golin at linaro.org>
> On 12 May 2016 at 17:07, Daniel Berlin via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > In my talks with a number of these projects, they pretty much don't care
> > what anyone else does, and plan to stick to their own import/etc
> > no matter what LLVM does with stable releases :)
> Is there anything we can do to make they care?
For all of them? Unequivocally: no.
You can define a subset of external customers you care about, and want to
work with you, and do something for them.
Whether you can get a subset that is large enough to reduce costs/burden
for you/distro folks is an unknown :)
> What I heard from them is that the upstream process wasn't clear
> enough with regards to fixes, API stability and process (which were
> pretty much echoed in this thread).
> Maybe, if we fix most of those problems, they would care more?
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. :)
IE you need an actual ordered hierarchy of who llvm, as a community, cares
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
And the answer can't be "everyone", because you have sets of customers
whose priorities and desires are often at odds with others.
(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")
> > (For reference, Google *ships* the equivalent of about 13-16 linux
> > distributions in products, uses about 5-6x that internally, and we have a
> > single monolithic source repository for the most part. I have the joy of
> > owning the third party software policies/etc for it, and so end up
> > responsible for trying to deal with maintaining single versions of llvm
> > tens to hundreds of packages).
> You sound like the perfect guy to describe a better upstream policy to
> please more users.
The problem is you may not like my policies ;)
At some point, at scale, you have to assign who bears the burden of various
We already do this a little bit in the community, telling people they need
to update tests for what their patches break, etc.
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.
> But I don't want to volunteer yourself. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev