From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11356 invoked by alias); 17 Nov 2006 15:19:11 -0000 Received: (qmail 11345 invoked by uid 22791); 17 Nov 2006 15:19:10 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 17 Nov 2006 15:19:02 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Gl5UX-0008GD-PB; Fri, 17 Nov 2006 10:18:57 -0500 Date: Fri, 17 Nov 2006 15:19:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: frozen variable objects Message-ID: <20061117151857.GB31319@nevyn.them.org> Mail-Followup-To: Nick Roberts , Vladimir Prus , gdb-patches@sources.redhat.com References: <17756.56523.353271.828046@kahikatea.snap.net.nz> <20061116220029.GA28461@nevyn.them.org> <17756.60994.909354.46765@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17756.60994.909354.46765@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00169.txt.bz2 On Fri, Nov 17, 2006 at 12:03:30PM +1300, Nick Roberts wrote: > > I'm not particularly inclined to wait, since none of this will show up > > unless your target / IDE specifically try to use it, but I'm sure I > > could be persuaded. > > If existing behaviour is broken it _should_ show up. A six month release cycle > doesn't seem long to wait especially coming from Emacs whose last mainline > release was Oct 2001 (GDB 5.3 was current when I started!). Maybe there is > another agenda with Emacs, I don't know, but presumably it will be released one > day and I would like it to work with current GDB when it is. I think Vladimir's said everything I would have said in response to this. Is your concern breaking your MI frontend in Emacs? If so, then you need to test - either routinely on HEAD, or if you have more limited time, then on release branches. That's why we keep release branches around for a few weeks and announce prereleases. Whether the patch lands on GDB 6.6 or 6.7 doesn't make much difference to the risk. If there's no testing, it might be released broken; if there is testing, it won't be. -- Daniel Jacobowitz CodeSourcery