From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26455 invoked by alias); 25 Mar 2005 19:47:54 -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 26412 invoked from network); 25 Mar 2005 19:47:44 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 25 Mar 2005 19:47:44 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DEun5-000680-Sy for ; Fri, 25 Mar 2005 14:48:20 -0500 Date: Fri, 25 Mar 2005 19:47:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: Product branches in the GDB repository? Message-ID: <20050325194819.GA23274@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20050322002034.GA19385@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050322002034.GA19385@nevyn.them.org> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00238.txt.bz2 On Mon, Mar 21, 2005 at 07:20:34PM -0500, Daniel Jacobowitz wrote: > 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. No one objected, and Stan supported the idea, so I am currently tagging csl-arm-20050325-branch. This is a release branch for our 2005-Q1 ARM toolchains; I intend for everything on the branch to be submitted to mainline eventually, but some bits will take time to review, and others may need interface changes before they are acceptable. There will be some native Windows patches and some remote protocol improvements in addition to ARM-only changes. Anyone have preferences on where to document branches? We don't currently do that in GDB. Easiest would be a file gdb/BRANCHES, parallel to binutils/BRANCHES, or on the "current CVS" page of the web site. -- Daniel Jacobowitz CodeSourcery, LLC