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

[Rafael Espíndola]

I think Diego implemented something like this for gcc at google.


On Friday, October 18, 2013, Joerg Sonnenberger wrote:

> Hi all,
> I mentioned this idea yesterday on IRC already and would like to discuss
> in the greater context of the mailing list. NetBSD is about to import
> LLVM and Clang into its repository; FreeBSD already has done that a
> while ago. This creates some interesting maintainance questions. FreeBSD
> has followed the LLVM/Clang releases and backported various fixes
> locally. NetBSD will after the 3.4 release likely end up doing the same.
> In the past, this process has created some fragmentation for GCC as
> various changed tended to accumulate over time. One part was always the
> somewhat tidious process of getting those changes upstream, the other
> problem was the difficulty of keeping track of who exactly had what
> state.
>
> Luckily with LLVM we are in much better position when it comes to
> getting changes integrated, so that's not an issue. There is still the
> problem of keeping track of who has which additional (bug fixing)
> patches and release management in general. For this purpose I would like
> to be able to create "vendor" branches in the main repository to reflect
> exactly what it is used by the corresponding downstream repository.
> This would increase the visibility of changes by any of the vendors
> involved, so that others can pick up the same changes. The impact on
> mailing list traffic should be low as changes are relatively rare
> compared to the rest of the development speed. Code access should follow
> similar practises as release management, e.g. every vendor branch has a
> code owner responsible for it.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <javascript:;>         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/20131018/6d52aeca/attachment.html>