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

[Joerg Sonnenberger]

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