From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3283 invoked by alias); 22 Mar 2005 00:20:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3253 invoked from network); 22 Mar 2005 00:20:26 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 22 Mar 2005 00:20:26 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DDX8M-00056F-VJ for ; Mon, 21 Mar 2005 19:20:35 -0500 Date: Tue, 22 Mar 2005 00:20:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Product branches in the GDB repository? Message-ID: <20050322002034.GA19385@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00197.txt.bz2 We're already pretty flexible about creating branches for development. Does anyone have an object to branches for non-FSF releases? I think it's a logical extension of current practice. CodeSourcery does regular releases of an ARM toolchain, and we're going to have a bunch of as yet unsubmitted GDB patches in our next release. Nothing deliberately unsubmitted, of course, but things which need additional polishing or review or input before they're ready for HEAD. I would prefer to maintain them in the main repository, simply because it's easier with CVS. And that way the patches are easily available for any curious GDB developers. FWIW, we already do this for both gcc and binutils. -- Daniel Jacobowitz CodeSourcery, LLC