<div dir="rtl"><div dir="ltr">Hi David,</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">The situation is similar to the Windows-specific patches now done for LLVM projects.</div><div dir="ltr"><br></div><div dir="ltr">
If a patch is applicable to other OS as well it's inserted in the main trunk as is.<br></div><div>If it's really specific to Windows it's #ifdef and accepted into the trunk. </div><div><br></div></div><div dir="ltr">
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.</div><div dir="ltr"><br></div><div dir="ltr">So LLVM is doing well without a Windows branch.</div>
<div dir="ltr"><br></div><div dir="ltr">Would FreeBSD be any different?<br></div><div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote"><div dir="ltr">2013/10/19 David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 19 Oct 2013, at 04:37, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
</div>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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
David<br>
<br>
[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.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>