From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31533 invoked by alias); 2 Jan 2003 17:34:16 -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 31523 invoked from network); 2 Jan 2003 17:34:16 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 2 Jan 2003 17:34:16 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18UB71-0000OH-00 for ; Thu, 02 Jan 2003 13:34:39 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18U9EQ-0004U0-00 for ; Thu, 02 Jan 2003 12:34:10 -0500 Date: Thu, 02 Jan 2003 17:34:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: GDB 5.3.1 vs 5.4/6.0 Message-ID: <20030102173409.GA17057@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <3E145BA0.4050403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E145BA0.4050403@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00019.txt.bz2 On Thu, Jan 02, 2003 at 03:32:48PM +0000, Andrew Cagney wrote: > Hello, > > First, don't forget that the 5.3 branch is open. Config and other fixes > can be committed. > > Still, the question is: should the next release be 5.3.1, or 5.4/6.0? > > 5.3.1 would be something like end Jan / start Feb. > 5.4/6.0 branch would be ~March. > > (As for 5.4 vs 6.0, I don't think the multi-arch goal will have been > achieved.) I recommend the way I've been doing binutils releases: leave the branch open for a little, and if people find things that they want fixed in a new release and handle getting them onto the branch, then do a 5.3.1 release. Don't soak massive development time into it. I have one issue that I would probably want fixed in a 5.3.1, which is that putting "call" in a breakpoints command list _still_ segfaults; there're two patches for this still awaiting review. One issue by itself isn't really enough to bother, though. Re multiarch: HP/PA is progressing and I can help on that if needed; I can even do the m32r if there is a perception that we still need it (is there?) since there conveniently are GCC, sim, and binutils ports to this target. z8k has binutils and sim but no GCC port as far as I can see; I could do it blindly, though, I wager - it's an impressively minimal GDB port. So if we want to hold out for multi-arch I bet we could do it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer