From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13478 invoked by alias); 2 Sep 2009 16:44:42 -0000 Received: (qmail 13469 invoked by uid 22791); 2 Sep 2009 16:44:41 -0000 X-SWARE-Spam-Status: No, hits=-2.4 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; Wed, 02 Sep 2009 16:44:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B57442BABC3 for ; Wed, 2 Sep 2009 12:44:33 -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 eAP6FrTzv+up for ; Wed, 2 Sep 2009 12:44:33 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7CE882BABC1 for ; Wed, 2 Sep 2009 12:44:33 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 35B6AF589A; Wed, 2 Sep 2009 09:44:25 -0700 (PDT) Date: Wed, 02 Sep 2009 16:44:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: [gdb-7.0 release] 2009-09-02 status and proposed plan Message-ID: <20090902164425.GR4379@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00023.txt.bz2 Hello everyone, I think everyone is anxious to see the next release out as fast as we can; it is going to be a major step forward compared to the previous releases! First, we need to make progress on the following documented issues: (a) Assert in frame.c:get_frame_arch Basically, we added an assertion to get_frame_arch, which should always be true. But to be safe, we decided to remove it from the release sources if the release branch was cut before we had enough time to field-test that change. We added that assertion in January, so I think we can skip that item. I don't think we ever tripped that assertion, did we? (b) Rename the python-support files to be 8.3-compliant. I thought that the change had been approved, but I see that the change has not been made. Has it been approved? If yes, it is being held up because we don't know how to best rename files without disturbing git? (c) varobj support for Python pretty-printing Tom gave a quick status on IRC yesterday. It sounds like there isn't much left to do. Perhaps a quick update on the Wiki page to state exactly what's left would be nice. Unless fixing the last thing or two might be faster ;-). (d) PR/9711: Quadratic slowdown for "where" command. Pending catastrophes, I should be able to fix that this week. (e) PR/9786: Typing "info frame" immediately after connecting to a remote target causes an assertion error on x86 GNU/Linux (32 bit). That's a real regression. I don't know that anyone ever looked at this issue. I did reproduce the issue many moons ago. I don't think it reproduces on x86_64. Any taker? (f) bug in breakpoint commands: commands not evaluated outside of main command loop. http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html There is a suggested patch, but needs looking at. Any taker? If there are any issue that you know of that are *RELEASE-CRITICAL* (build failure, regressions), please let us know, so we can decide what to do, and possibly add it to the 7.0 TODO list. Anything else, I suggest, should no longer be a priority for 7.0. In terms of dates, I would like us to try to release sooner rather than later. Can I suggest we try to shoot for Wed Sep 9th for the branch date, and then try to release a couple of weeks after (that would be the 23rd)? If there are any fixes that would be nice for the release but don't make it to the 23rd, we can always have a corrective 7.0.1 release mid December. Also, it sounds like a lot more new features are currently being developed, and people are trying to make it for 7.0. I propose to release 7.1 not too long after 7.0: Instead of waiting 6 months, we could release around end of January, early Feb (say: branch mid Jan, release end of Jan). Thoughts? Doug, you asked for a couple of weeks notice for 7.0. I'm being a little more aggressive. Is this going to be an issue for you? -- Joel