llvm dev - Oct 2013 - [LLVMdev] Downstream distributions as first class citizens in the LLVM repository

On Sat, Oct 19, 2013 at 06:47:51AM +0700, "C. Bergstr?m"
wrote:
> <snip />
> 
> May I just add a few points
> 
> 1) Won't get rid of forks - ever.. forget it
> 2) Branches are "free" - having a single branch for dumping
things is
> unlikely to suit the needs of all the work by everyone
I think that having a single stable branch would be the most efficient way to
track bug fixes for older versions, and help reduce the maintenance
burden on people distributing LLVM.  If the stable branch doesn't suit
someone's needs then they can still maintain their own branches using the
stable branch as a base.  This would be my preference.

That being said, I think the multiple vendor branches would still be
an improvement over what we have now, and I would sign up for a
Mesa branch if this is the way the community decides to go.

-Tom
> 3) Having things consolidated in one more or less easy to find place is 
> better than all over the damn place.
> ------------
> I'd vote to give FBSD and anyone "reasonable" a branch to
contribute
> whatever they feel is worth it. Assuming FreeBSD agrees to keep this 
> "upstream" branch in align with whatever they have in the ports
tree -
> it makes the patches they are carrying a lot more visible and 
> /potentially/ easier for keeping in sync with upstream.
> 
> Can anyone from NetBSD or FreeBSD chime in on this - would it be a 
> reasonable request for ports + the branch to stay in sync?
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Oct 18, 2013, at 7:07 PM, Tom Stellard <tom at stellard.net> wrote:
> On Sat, Oct 19, 2013 at 06:47:51AM +0700, "C. Bergstr?m" wrote:
>> <snip />
>> 
>> May I just add a few points
>> 
>> 1) Won't get rid of forks - ever.. forget it
>> 2) Branches are "free" - having a single branch for dumping
things is
>> unlikely to suit the needs of all the work by everyone
> 
> I think that having a single stable branch would be the most efficient way
to
> track bug fixes for older versions, and help reduce the maintenance
> burden on people distributing LLVM.  If the stable branch doesn't suit
> someone's needs then they can still maintain their own branches using
the
> stable branch as a base.  This would be my preference.
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.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/8573e406/attachment.html>

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.