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

[Yaron Keren]

Hi David,

The situation is similar to the Windows-specific patches now done for LLVM
projects.

If a patch is applicable to other OS as well it's inserted in the main
trunk as is.
If it's really specific to Windows it's #ifdef and accepted into the trunk.

Either case it's usually a negligible burden for the developer submitting
Windows patches to make sure his patch plays well with the main trunk.

So LLVM is doing well without a Windows branch.

Would FreeBSD be any different?

Yaron




2013/10/19 David Chisnall <David.Chisnall at cl.cam.ac.uk>

> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131019/e8b709e9/attachment.html>