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

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...

Joerg

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.

-Tom
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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.

Joerg