This is the mail archive of the
mailing list for the binutils project.
Re: git is live
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Peter Bergner <bergner at vnet dot ibm dot com>, Tom Tromey <tromey at redhat dot com>, GDB Development <gdb at sourceware dot org>, Binutils Development <binutils at sourceware dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot ibm dot com>
- Date: Thu, 14 Nov 2013 15:11:40 +0400
- Subject: Re: git is live
- Authentication-results: sourceware.org; auth=none
- References: <877gd5iyaz dot fsf at fleche dot redhat dot com> <1382709091 dot 5918 dot 9 dot camel at otta> <CAKOQZ8xh2L_D-gdX2wG7TT0c-r6q4=QXqqFHiUq2WPO-3b3t-Q at mail dot gmail dot com> <5284ACD1 dot 8090609 at arm dot com>
> > GCC has always allowed vendor branches. I don't see any reason that
> > binutils/gdb should prohibit them. Obviously all the code has to be
> > under the GPL or some other explicitly permitted license.
> I believe the GCC policy is that the code must also be assigned to the
> FSF, just as it would be for trunk.
Outside of the policy, I am starting to rethink the policy of
allowing vendor branches. For centralized version control systems
such as SVN, it makes sense, because there is no other choice.
But for decentralized systems such as git, I think vendor branches
could be just as easily hosted elsewhere. With git, it's really easy
for anyone to host it somewhere, and publish its location. It's also
equally easy for anyone interested in the work to add that location
a remote, and fetch from it.
We could allow exceptions on a case-by-case basis; for instance
we'd allow it if some contributor was constrained by his employer.
But otherwise, everyone who uses the default "fetch" ends up
fetching everything, including vendor branches that they are
not interested in.