From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23989 invoked by alias); 3 Sep 2009 02:05:14 -0000 Received: (qmail 23878 invoked by uid 22791); 3 Sep 2009 02:05:12 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f181.google.com (HELO mail-pz0-f181.google.com) (209.85.222.181) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Sep 2009 02:05:05 +0000 Received: by pzk11 with SMTP id 11so396753pzk.13 for ; Wed, 02 Sep 2009 19:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.20.29 with SMTP id x29mr187424wfi.182.1251943504086; Wed, 02 Sep 2009 19:05:04 -0700 (PDT) In-Reply-To: <20090902164425.GR4379@adacore.com> References: <20090902164425.GR4379@adacore.com> From: Hui Zhu Date: Thu, 03 Sep 2009 02:05:00 -0000 Message-ID: Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan To: Joel Brobecker Cc: gdb@sourceware.org, Michael Snyder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00028.txt.bz2 Hi Joel, Thanks for your work. Gdb-cvs-head have a build error in cygwin with "--enable-targets=3Dall --enable-64-bits-bfd". http://sourceware.org/ml/gdb-patches/2009-08/msg00559.html I had post a patch for it. It still in discussion. http://sourceware.org/ml/gdb-patches/2009-08/msg00574.html Thanks, Hui On Thu, Sep 3, 2009 at 00:44, Joel Brobecker wrote: > 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: > > =A0(a) Assert in frame.c:get_frame_arch > =A0 =A0 =A0Basically, we added an assertion to get_frame_arch, which shou= ld > =A0 =A0 =A0always be true. But to be safe, we decided to remove it from > =A0 =A0 =A0the release sources if the release branch was cut before we had > =A0 =A0 =A0enough time to field-test that change. =A0We added that assert= ion > =A0 =A0 =A0in January, so I think we can skip that item. =A0I don't think= we > =A0 =A0 =A0ever tripped that assertion, did we? > > =A0(b) Rename the python-support files to be 8.3-compliant. > =A0 =A0 =A0I thought that the change had been approved, but I see that > =A0 =A0 =A0the change has not been made. =A0Has it been approved? If yes, > =A0 =A0 =A0it is being held up because we don't know how to best rename > =A0 =A0 =A0files without disturbing git? > > =A0(c) varobj support for Python pretty-printing > =A0 =A0 =A0Tom gave a quick status on IRC yesterday. It sounds like > =A0 =A0 =A0there isn't much left to do. Perhaps a quick update on the Wiki > =A0 =A0 =A0page to state exactly what's left would be nice. =A0Unless fix= ing > =A0 =A0 =A0the last thing or two might be faster ;-). > > =A0(d) PR/9711: Quadratic slowdown for "where" command. > =A0 =A0 =A0Pending catastrophes, I should be able to fix that this week. > > =A0(e) PR/9786: Typing "info frame" immediately after connecting to > =A0 =A0 =A0a remote target causes an assertion error on x86 GNU/Linux (32= bit). > =A0 =A0 =A0That's a real regression. =A0I don't know that anyone ever loo= ked > =A0 =A0 =A0at this issue. I did reproduce the issue many moons ago. I don= 't > =A0 =A0 =A0think it reproduces on x86_64. =A0Any taker? > > =A0(f) bug in breakpoint commands: commands not evaluated outside of > =A0 =A0 =A0main command loop. > =A0 =A0 =A0http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html > =A0 =A0 =A0There 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 >