From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2021 invoked by alias); 17 Nov 2006 20:52:33 -0000 Received: (qmail 2013 invoked by uid 22791); 17 Nov 2006 20:52:33 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Nov 2006 20:52:27 +0000 Received: from kahikatea.snap.net.nz (p202-124-124-104.snap.net.nz [202.124.124.104]) by viper.snap.net.nz (Postfix) with ESMTP id 9EBA43D9120; Sat, 18 Nov 2006 09:52:52 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 31AD4BE43E; Sat, 18 Nov 2006 09:48:25 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17758.8216.142597.547417@kahikatea.snap.net.nz> Date: Fri, 17 Nov 2006 20:52:00 -0000 To: Daniel Jacobowitz Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: frozen variable objects In-Reply-To: <20061117151857.GB31319@nevyn.them.org> References: <17756.56523.353271.828046@kahikatea.snap.net.nz> <20061116220029.GA28461@nevyn.them.org> <17756.60994.909354.46765@kahikatea.snap.net.nz> <20061117151857.GB31319@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.90.14 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/msg00183.txt.bz2 > I think Vladimir's said everything I would have said in response to > this. He said (I had to read the archives as I'm not subscribed to gdb-patches): ...it seems to me that frontend authors are much better testing branch before it's realeased than random CVS state, If the CVS state is indeed random then that must reflect poorly on the review process. > 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. If the changes go in after the release I generally have six months to spot a bug, if they go in now I'll have roughly two weeks. But I find something else anomalous about this. Vladimir (on behalf of Codesourcery?) submits a patch for MI which has 26 hunks which you're proposing to approve in three days, just as a release is coming up. I have submitted many patches over the last year which still not been reviewed/approved. Notably one patch for -var-set-format which is just a one line change: http://sourceware.org/ml/gdb-patches/2006-05/msg00348.html resubmitted in August: http://sourceware.org/ml/gdb/2006-08/msg00179.html and one to fix an _existing_ bug (PR mi/2077): http://sourceware.org/ml/gdb-patches/2006-10/msg00239.html This does not seem impartial use of resources to review MI changes. To balance that I must add that GDB development benefits immensely from Codesourcery and I appreciate that you do a huge amount of work for no personal gain. > 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. I have no formal testing process. I just use it and see if it breaks. -- Nick http://www.inet.net.nz/~nickrob