From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5924 invoked by alias); 17 Nov 2006 21:05:14 -0000 Received: (qmail 5916 invoked by uid 22791); 17 Nov 2006 21:05:13 -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 21:05:07 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GlAtR-0003X1-Jx; Fri, 17 Nov 2006 16:05:01 -0500 Date: Fri, 17 Nov 2006 21:05:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: frozen variable objects Message-ID: <20061117210501.GA13104@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> <20061117151857.GB31319@nevyn.them.org> <17758.8216.142597.547417@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17758.8216.142597.547417@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/msg00184.txt.bz2 On Sat, Nov 18, 2006 at 09:48:24AM +1300, Nick Roberts wrote: > > 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. I don't get the fuss. It's not an immensely destabilizing change or a huge new subsystem. Why should it be treated separately from any other patch posted in the last few months, in the later half of a release gap? GCC needs to enforce a three-stage system, but we don't. We keep GDB working from trunk pretty much all of the time. I think we do, in that regard, a great job. > 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. Let me be perfectly clear about this. I can spend a certain amount of my work time reviewing community patches, because my employer is very understanding about the FSF development process. I'm lucky in that respect and hopefully so is GDB. I can spend a great deal more of my work time reviewing patches that are directly to my employer's benefit and I do precisely that. Similarly I can spend much more time writing patches that are useful to my employer (e.g. flash support) than I can on things I just think would be good (e.g. several thousand lines of pointer to member improvements that I still haven't gotten committed). Don't misunderstand me, I think the things I'm doing at work for GDB are cool and good to have even in the FSF tree - otherwise we'd just keep an internal fork. But they tend to be of more use to embedded developers than non-embedded because that's where we presently have more customers. I still spend both work and personal time reviewing GDB patches. I spend far more time than I want to doing this. I'd rather be writing my own patches. Even so, the load of unreviewed patches far exceeds what I can do on my own. I have no chance whatsoever of keeping up. I have all your unreviewed patches flagged in my inbox, and I'll probably get to them someday, but there are no extra hours in my day. I am rapidly approaching burnout on GDB patch review. I may stop doing it entirely just to keep my sanity and have a little bit of my free time back. I appreciate that you fix things, especially those MI PRs. I will somehow get to them. But, good lord, I need more help from other maintainers! And more maintainers. All: Should Nick be an MI maintainer now? -- Daniel Jacobowitz CodeSourcery