From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14882 invoked by alias); 9 Apr 2014 17:58:19 -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 14866 invoked by uid 89); 9 Apr 2014 17:58:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: elasmtp-scoter.atl.sa.earthlink.net Received: from elasmtp-scoter.atl.sa.earthlink.net (HELO elasmtp-scoter.atl.sa.earthlink.net) (209.86.89.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Apr 2014 17:58:17 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WXwlL-0001mS-OI for gdb@sourceware.org; Wed, 09 Apr 2014 13:58:15 -0400 Message-ID: <53458A37.2050002@earthlink.net> Date: Wed, 09 Apr 2014 17:58:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Vendor branches on sourceware.org's binutils-gdb repo References: <53406399.9050303@linux.vnet.ibm.com> In-Reply-To: <53406399.9050303@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da9403c369bc9aa01920c77f70902f20f6aa8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00031.txt.bz2 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. Stan