This is the mail archive of the
mailing list for the binutils project.
Re: Vendor branches on sourceware.org's binutils-gdb repo
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Edjunior Barbosa Machado <emachado at linux dot vnet dot ibm dot com>
- Cc: GDB <gdb at sourceware dot org>, Binutils <binutils at sourceware dot org>, Peter Bergner <bergner at vnet dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Sun, 06 Apr 2014 03:02:49 -0300
- Subject: Re: Vendor branches on sourceware.org's binutils-gdb repo
- Authentication-results: sourceware.org; auth=none
- References: <53406399 dot 9050303 at linux dot vnet dot ibm dot com>
On Saturday, April 05 2014, Edjunior Barbosa Machado wrote:
> Hi all,
> We already maintain community vendor branches for glibc (on
> sourceware.org) and gcc (on gnu.org), and we'd like to do the same for
> binutils-gdb. The idea is to create separate namespaces, i.e.
> ibm/gdb/7.7 and ibm/binutils/2.24. Those branches will only store
> patches under GPL and with a proper copyright assignment.
> Any comments? Objections?
Hm, just a comment, but nothing major or blocker. I understand the need
for vendor branches, but I also think that we should make more use of
git's distributed model. For example, why can't Company X (I am not
criticizing anyone particularly, really) create and maintain its own git
repository, with all the necessary branches there? Wouldn't that be
better than (a) "polluting" sourceware's repository and (b) putting an
extra pressure on sourceware's infra?
I may be missing some detail here, and if that is the case then I am
sorry for creating unecessary noise, but at first glance I couldn't come
up with a decent answer for my question above.
P.S.: Before I forget, this comment/question really applies to everyone
who is still using sourceware as their "personal" git repo.
P.S. 2: It is also worth mentioning that my intention is *not* to make
people create GitHub accounts and start doing things there. Aside from
the fact that GitHub uses non-free software to run its services (and
within its "social network" walls and makes it a little harder to get
advantage from git's distributed protocol.