From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7899 invoked by alias); 3 Sep 2009 19:26:17 -0000 Received: (qmail 7889 invoked by uid 22791); 3 Sep 2009 19:26:16 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Sep 2009 19:26:05 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B7BF02BAB1F; Thu, 3 Sep 2009 15:26:03 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sqKLNENVboWi; Thu, 3 Sep 2009 15:26:03 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 779B82BAB12; Thu, 3 Sep 2009 15:26:03 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B7CB8F589A; Thu, 3 Sep 2009 12:25:52 -0700 (PDT) Date: Thu, 03 Sep 2009 19:26:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb@sourceware.org Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan Message-ID: <20090903192552.GC4379@adacore.com> References: <20090902164425.GR4379@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00049.txt.bz2 > Joel> (b) Rename the python-support files to be 8.3-compliant. [...] > I'm ok with the simple rm + add approach. I agree. Let's apply the patch ASAP. Do you happen to have a rebased version of the patch somewhere in archer, by any chance? Otherwise, I'll try to contact Thiago to get the latest version and work from there. > There are a number of other unreviewed patches. I can try to make a > list if that would be helpful. I think it would. We need to draw our attention to everything that needs to be done before branching. > I would like us to commit to reviewing all patches that arrived before > some cutoff date before the release. I think this is important to > encourage continued contributions to GDB. Also, I consider this part > of our duty as maintainers. I would agree with that, but it means that we need to firmly commit to the release. I'm available, but if it's just two or three of us, this is just going to be too much work. I understand that someone might be disappointed that his patch does not make the next release, but should we really delay this further for things like minor enhancements for instance? I propose the following approach: Let's commit to reviewing promptly all patches that are posted before branch time. Patches that are safe for the branch will be added and part of the 7.0.1 release. Others should not be checked in at such a late stage anyway (IMO). What do you think? > I think the "Fix Darwin breakage" and "Speed up find_pc_section" threads > need to reach some sort of resolution. I haven't caught up on these > yet, so maybe these are already concluded. OK - I added these two to the wiki page. I have completely zapped most threads while I was away. Would you mind posting URLs to these discussions for me? > Finally, I think we should get the DW_OP_*_value patch in. This patch > is needed with GCC svn trunk, now that VTA has gone in. (I'm working on > the final bit of this patch: the test cases.) I see that you posted the patch (as an RFC. I will take a look, although I'm not very familiar with this area). Perhaps we could coerce Daniel to give his opinion on this? > It seems possible, at least if people step up for the remaining tasks. Yeah, that's the problem. On the couple of issues that I pointed out, no one really stepped up to the plate :-(. I'll take a look at frame assertion failure with gdbserver, but it'd be nice to get some help fixing the rest. -- Joel