From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23378 invoked by alias); 9 Apr 2014 18:41:05 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 23367 invoked by uid 89); 9 Apr 2014 18:41:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f179.google.com Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com) (209.85.128.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 09 Apr 2014 18:41:03 +0000 Received: by mail-ve0-f179.google.com with SMTP id db12so2430209veb.38 for ; Wed, 09 Apr 2014 11:41:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cha5cYjjoy0NRIrzo4kvolirIudRkQg/SutK8kwUAPc=; b=dC9MnZxGCNqBhLm8K2bf2i49mS0DDlYalzqK1+e9soczeo966Jcwv3YPxS65n85mQf 4Oo4NM/p4iqKbeAmHXXvqK4X5yPV8/hZf5NcFTMnUP+Nod2eIxdCFarUkzmT5P1UFNst tdFY4Y7OPlxe4zukjincUtfYyaeIiOdFl0ZAb6hX39vZNHnycLq7p1dB7hr9pI6TNfRU EHvUe2XgBP84egKh1igJWDwmqdaUaaklC+zvbprnBstSnTzdRdWJZ4dhBA7CJsSeKUQB DVj4yCFkwRKIYADsoUJV3vybKxXe88hZ/LABp1t2vaS9d5OKg+We/tL4zgdmpyd26hsk 12iA== X-Gm-Message-State: ALoCoQk/pr7v4s6JItxkmTyybl9WXT+z02QIa+MZ9Y+OqEY0xKCeOZmMaHhfCAmFv2CcwYoi1kgXkUVGL9A+A/DcquQQKE4jbEJAYdeScTWZOa0UEpOAHavnm+xtFudWHiSlkokmFyA8gTrbnN/lmB4L5600b+Z7qrfRtXljnZuiLEm4ri/tJXfIb64c1YSqumQGTaM/Ebqm MIME-Version: 1.0 X-Received: by 10.52.130.225 with SMTP id oh1mr8470893vdb.8.1397068861362; Wed, 09 Apr 2014 11:41:01 -0700 (PDT) Received: by 10.52.13.101 with HTTP; Wed, 9 Apr 2014 11:41:01 -0700 (PDT) In-Reply-To: <53458A37.2050002@earthlink.net> References: <53406399.9050303@linux.vnet.ibm.com> <53458A37.2050002@earthlink.net> Date: Wed, 09 Apr 2014 18:41:00 -0000 Message-ID: Subject: Re: Vendor branches on sourceware.org's binutils-gdb repo From: Doug Evans To: Stan Shebs Cc: gdb Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00033.txt.bz2 On Wed, Apr 9, 2014 at 10:58 AM, Stan Shebs 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.