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

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

<snip />

May I just add a few points

1) Won't get rid of forks - ever.. forget it
2) Branches are "free" - having a single branch for dumping things is 
unlikely to suit the needs of all the work by everyone
3) Having things consolidated in one more or less easy to find place is 
better than all over the damn place.
------------
I'd vote to give FBSD and anyone "reasonable" a branch to
contribute
whatever they feel is worth it. Assuming FreeBSD agrees to keep this 
"upstream" branch in align with whatever they have in the ports tree -
it makes the patches they are carrying a lot more visible and 
/potentially/ easier for keeping in sync with upstream.

Can anyone from NetBSD or FreeBSD chime in on this - would it be a 
reasonable request for ports + the branch to stay in sync?

On Sat, Oct 19, 2013 at 06:47:51AM +0700, "C. Bergstr?m"
wrote:
> <snip />
> 
> May I just add a few points
> 
> 1) Won't get rid of forks - ever.. forget it
> 2) Branches are "free" - having a single branch for dumping
things is
> unlikely to suit the needs of all the work by everyone
I think that having a single stable branch would be the most efficient way to
track bug fixes for older versions, and help reduce the maintenance
burden on people distributing LLVM.  If the stable branch doesn't suit
someone's needs then they can still maintain their own branches using the
stable branch as a base.  This would be my preference.

That being said, I think the multiple vendor branches would still be
an improvement over what we have now, and I would sign up for a
Mesa branch if this is the way the community decides to go.

-Tom
> 3) Having things consolidated in one more or less easy to find place is 
> better than all over the damn place.
> ------------
> I'd vote to give FBSD and anyone "reasonable" a branch to
contribute
> whatever they feel is worth it. Assuming FreeBSD agrees to keep this 
> "upstream" branch in align with whatever they have in the ports
tree -
> it makes the patches they are carrying a lot more visible and 
> /potentially/ easier for keeping in sync with upstream.
> 
> Can anyone from NetBSD or FreeBSD chime in on this - would it be a 
> reasonable request for ports + the branch to stay in sync?
> 
> _______________________________________________
> 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 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>