[llvm-dev] LLVM Releases: Upstream vs. Downstream / Distros

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Thu May 12 08:15:39 PDT 2016

On 12 May 2016 at 15:56, Kristof Beyls <Kristof.Beyls at arm.com> wrote:
> We find that when we find a regression within 24 to 48 hours of the commit introducing it,
> it's much cheaper to get it fixed.

Hi Kristof,

Indeed, that is true.

But there are so much additional (internal) buildbots can do. If you
have any additional validation steps that you only do when you pick a
candidate for release, and there are failures in that set, you won't
see them during the trunk monitoring.

Also, distributions don't have as many compiler developers as most
groups releasing toolchains, and they have to rely on the public
buildbots (which are by no means comprehensive).

This is not about downstream *development*, but downstream *release*
process, which in most situations, require additional validation.

Following trunk for your development process is cheaper, as you said,
and most people agree. But if you release your product a few weeks
after the release is out, it may be better to get the release itself,
since it has been validated but many other groups (assuming everyone
join in), than trunk.

> 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.

That's the balance I'm trying to get right. :)

There's also the other topic about the community.

LLVM is mostly a tool kit for compilers, yes, and most LLVM developers
are using it as such. But more and more projects are depending on the
actual compiler solution (Clang+LLVM+RT), and by the reaction of most
distros I've spoken to, we could improve our OSS community
interactions quite a lot.

I can certainly understand why most companies are worried about their
own processes, but that's undermining the ability of the OSS release
to achieve it's goal, which is to be used to build all kinds of
software in the wild.

We have FreeBSD, Mandriva and Android using it by default, which is a
*big* win. We have Debian, RedHat and Canonical worried about the
integration of LLVM in their packages, that's awesome.

I just want us to look at that picture, and see if we can do anything
better for them, that will in turn, make our processes slightly
cheaper because of the synergy it will create.


More information about the llvm-dev mailing list