From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17707 invoked by alias); 3 Sep 2009 20:12:06 -0000 Received: (qmail 17698 invoked by uid 22791); 3 Sep 2009 20:12:05 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Sep 2009 20:11:57 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n83KBESe017782; Thu, 3 Sep 2009 16:11:14 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n83KBDcH007484; Thu, 3 Sep 2009 16:11:13 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n83KBCN7005469; Thu, 3 Sep 2009 16:11:12 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 944E9378242; Thu, 3 Sep 2009 14:11:11 -0600 (MDT) From: Tom Tromey To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan References: <20090902164425.GR4379@adacore.com> <20090903192552.GC4379@adacore.com> Reply-To: Tom Tromey Date: Thu, 03 Sep 2009 20:12:00 -0000 In-Reply-To: <20090903192552.GC4379@adacore.com> (Joel Brobecker's message of "Thu, 3 Sep 2009 12:25:52 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00054.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Tom> I'm ok with the simple rm + add approach. Joel> I agree. Let's apply the patch ASAP. Do you happen to have a Joel> rebased version of the patch somewhere in archer, by any chance? No, I'm afraid not. Tom> There are a number of other unreviewed patches. I can try to make a Tom> list if that would be helpful. Joel> I think it would. We need to draw our attention to everything that Joel> needs to be done before branching. My list is probably incomplete, since I have not been systematic about tracking patches. That said, patch submitters do bear some burden to ping their patches and to otherwise irritate a maintainer into responding ;) * The catch syscall patches. I didn't dig up the URLs for these. * Caz Yokoyama's kgdb patch. I don't think the most recent one was ever reviewed. http://permalink.gmane.org/gmane.comp.gdb.patches/50989 * Watchpoint on an unloaded shared library http://permalink.gmane.org/gmane.comp.gdb.patches/46187 http://permalink.gmane.org/gmane.comp.gdb.patches/46290 * gdb.objc/objcdecode.exp test error http://permalink.gmane.org/gmane.comp.gdb.patches/47073 * Xtensa backtrace http://permalink.gmane.org/gmane.comp.gdb.patches/48614 * Fix breakpoints when several source files have the same name http://permalink.gmane.org/gmane.comp.gdb.patches/49047 * Jonas Maebe's calling convention patch, pinged twice. http://permalink.gmane.org/gmane.comp.gdb.patches/49467 * Nathan Froyd's internal error patch, pinged once. http://permalink.gmane.org/gmane.comp.gdb.patches/50458 * Paul Pluzhnikov's pending patches. He pinged these recently: http://sourceware.org/ml/gdb-patches/2009-08/msg00372.html http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html * Jan Kratochvil's watchpoint series. First one: http://permalink.gmane.org/gmane.comp.gdb.patches/51128 * Sami Wagiaalla's namespace patches. http://permalink.gmane.org/gmane.comp.gdb.patches/51166 http://permalink.gmane.org/gmane.comp.gdb.patches/51167 * Use external editor in 'commands' command http://permalink.gmane.org/gmane.comp.gdb.patches/51394 * Keith's recent dwarf2/c++ patches. There are a couple other biggish pending things I remember: Vala and D support, but those are stalled for some reason on the submitter side (lack of activity or waiting for paperwork). I've meant to review some of these, but of course it is tough to get to them all. And, there are several in here that I won't review as I don't have the necessary expertise. I'm not sure whether any of these require paperwork, either. Joel> I understand that someone might be disappointed that his patch Joel> does not make the next release, but should we really delay this Joel> further for things like minor enhancements for instance? I just wanted to encourage maintainers to make an extra effort. I agree we shouldn't delay the release for anything minor. Joel> I propose the following approach: Let's commit to reviewing promptly Joel> all patches that are posted before branch time. Patches that are safe Joel> for the branch will be added and part of the 7.0.1 release. Others Joel> should not be checked in at such a late stage anyway (IMO). What do Joel> you think? Yes, sounds good to me. Tom