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

[Sean Silva]

On Fri, Oct 18, 2013 at 7:35 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Fri, Oct 18, 2013 at 07:28:28PM -0400, Tom Stellard wrote:
> > On Sat, Oct 19, 2013 at 01:07:49AM +0200, Joerg Sonnenberger wrote:
> > > On Fri, Oct 18, 2013 at 06:47:55PM -0400, Tom Stellard wrote:
> > > > On Fri, Oct 18, 2013 at 07:09:47PM +0200, 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.
> > > >
> > > > I would really like to have something like this.  However, I think
> there
> > > > should be just be one 'vendor' branch.  There are already way too
> many
> > > > forks of LLVM both public and private and having a common branch for
> > > > fixes would be very beneficial and save everyone a lot of work.
>  Plus,
> > > > I think it would give users with private forks of LLVM an incentive
> to
> > > > contribute changes back to the project.
> > >
> > > Having a single branch doesn't work as soon as maintaince for releases
> > > comes into the game. Consider FreeBSD 10 shipping with Clang 3.3 and
> > > FreeBSD 11 with Clang 3.4...
> > >
> >
> > Of course, what I meant was there should be one branch per version of
> > clang/llvm.  I thought the suggestion was that there should be a NetBSD
> > branch, a FreeBSD branch, an Ubuntu branch, etc.
>
> Yes. Still the same issue applies -- it is quite difficult to keep
> downstream always in sync, especially if one platform cares about
> certain changes and others don't.
>

Could you maybe give a sampler of the kinds of things that would cause
problems?


>
> Joerg
> _______________________________________________
> 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/20131018/25844456/attachment.html>