[LLVMdev] Downstream distributions as first class citizens in the LLVM repository

[David Chisnall]

On 19 Oct 2013, at 04:37, Chris Lattner <clattner at apple.com> wrote:

> I agree.  I don't see how a concept of "official vendor branches" is better than the concept of "stable" branches that take bugfixes.  I think it would be simple and work well to just have vendors ask to get patches merged into 3.3.x or 3.4.x (whichever they are based on) stabilization branches, and then do their releases from that.

In the FreeBSD tree, we would happily take a patch that fixed a bug that appeared on FreeBSD, even if it caused unacceptable performance regressions on OS X (for example).  I would not expect an LLVM stable branch to do the same.

We also have potentially different requirements for ABI stability.  We intend to ship clang, LLDB, and some binutils-like tools linked against LLVM libraries, but we explicitly do not support linking anything outside the base system against these libraries, and upgrades to the base system happen atomically.  This means that we'd be happy with ABI breakage, as long as APIs used by these components were unchanged (or were simultaneously updated).  In contrast, one of the goals of the stable branch that we discussed would be ABI stability.

I'm not entirely sure that there is a big advantage to having the FreeBSD-LLVM[1] in the LLVM tree.  We import a snapshot of LLVM into the vendor branch in the FreeBSD tree and then merge it.  It's quite easy for us to see any locally-applied diffs.  Copying there from some LLVM-hosted svn branch wouldn't be any easier than copying there from trunk.

David

[1] We actually have a few forks of LLVM in various Perforce branches and git repositories with experimental features too, although most of those are intended to be merged upstream eventually.