llvm dev - May 2016 - LLVM Releases: Upstream vs. Downstream / Distros

I'll bite:

Do you really believe you could ever get these folks to choose consistent
llvm versions anyway?

Or will you always have to do the work yourself anyway?

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 schedules
no matter what LLVM does with stable releases :)

(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 for
tens to hundreds of packages).


On Thu, May 12, 2016 at 8:27 AM, Bernhard Rosenkränzer <
llvm-dev at lists.llvm.org> wrote:
> On 12 May 2016 at 16:56, Kristof Beyls <Kristof.Beyls at arm.com>
wrote:
>
>> In my opinion, it would be better overall for the LLVM project if
>> top-of-trunk is
>> tested as much as possible, if testing resources are so scarce that a
>> choice
>> has to be made between testing top-of-trunk or testing a release
branch.
>>
>
> I agree that trunk is more important, with both of my hats on.
>
> But releases are not completely irrelevant - one thing making them
> important is the fact that there's other projects out there using the
LLVM
> libraries - and as a distro, we have to make sure they all work (so they
> agree on the same API), preferably without having to ship multiple versions
> of LLVM and preferably without having to patch external code too much to
> adjust to API changes.
>
> In OpenMandriva, we have to keep Mesa, creduce, emscripten and the
> LLVMified Qt moc working (list expected to grow -- ultimately we'd also
> like to use the system LLVM libraries for the swift compiler).
> In AOSP, RenderScript relies on the LLVM API, but there's nothing else
> using it, so there's currently no need to force a common version of the
API
> between different projects there.
>
> ttyl
> bero
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/6d7287db/attachment.html>

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 schedules
> no matter what LLVM does with stable releases :)
Is there anything we can do to make they care?

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?


> (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 for
> tens to hundreds of packages).
You sound like the perfect guy to describe a better upstream policy to
please more users.

But I don't want to volunteer yourself. :)

--renato

On Thu, May 12, 2016 at 9:12 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> 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
> schedules
> > 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
about supporting.
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
> for
> > 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
support-like things.

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. :)
>
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/567d0052/attachment.html>