Re: Vendor branches on sourceware.org's binutils-gdb repo

On Wed, Apr 9, 2014 at 10:58 AM, Stan Shebs <[email protected]> wrote:
> On 4/5/14 1:12 PM, Edjunior Barbosa Machado wrote:
>> Hi all,
>>
>> at the time when binutils/gdb was moving to git, there has been some
>> discussion in the mailing list [1] about the possibility of hosting
>> vendor branches on sourceware.org's binutils-gdb git repository but, as
>> far as I understood, there has been no agreement about this policy.
>
> One small point in favor of vendor branches is that it ensures we
> have the code already in hand - if a project goes on the back burner,
> or changes ownership, or an admin leaves, the vendor repo can disappear
> overnight.
>
> On the question of space and activity, are there vendor branches that
> are really so much more active than our trunk?  I would expect them
> be to relatively quiet most of the time, vendor branches typically
> having fewer people doing work on them.

fwiw,
I really like irker's reports on #gdb for the trunk.
OTOH, the S/N ratio on #gdb will monotonically drop over time as use
of vendor branches on binutils-gdb scales up.  There are days when the
S/N ratio on #gdb would drop to barely useful with the branches that
are there now.  If it is really hard to *only* show trunk commits on
#gdb, that is, IMO, a strong argument in favor of putting vendor
branches in a different repo.
*If* one really wanted irker even with it having to report commits in
all branches then one *could* have a separate channel, but it's not my
first choice (or possibly second choice even).
OTOH, #gdb has been relatively quiet for vendor-branch commits
recently, maybe this has already been fixed?

I'm ok with a binutils-gdb-vendor repo or some such.  Seems like it
should be trivial for overseers to set up (I'm assuming people won't
want a copy of trunk in this repo with a cron job, or some such, to
keep it up to date, or any other such time commitment from overseers).
 Whether a separate vendor repo uses materially more resources, I
don't know.