From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29644 invoked by alias); 16 Sep 2009 06:47:21 -0000 Received: (qmail 29626 invoked by uid 22791); 16 Sep 2009 06:47:19 -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-f171.google.com (HELO mail-pz0-f171.google.com) (209.85.222.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 06:47:15 +0000 Received: by pzk1 with SMTP id 1so1567599pzk.13 for ; Tue, 15 Sep 2009 23:47:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.210.13 with SMTP id i13mr646386wfg.304.1253083633064; Tue, 15 Sep 2009 23:47:13 -0700 (PDT) In-Reply-To: <20090902164425.GR4379@adacore.com> References: <20090902164425.GR4379@adacore.com> From: Hui Zhu Date: Wed, 16 Sep 2009 06:47: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/msg00212.txt.bz2 Hi Joel, I think it's very close to branch. But prec still have some patches isn't in. I am not sure they can in 7.0 or not. Could you please help me with it? Thanks a lot. :) 1. [RFA] Make the prec support signal better Michael have check-in the test for signal. Without these patches. Testsuite will get fail. 2. Record segfault I posted a patch for it. 3. [RFA] let record_resume fail immediately on error Sames like 1. 4. [RFA] reverse debugging tests I think this patch can make reverse test more better. 5. set record query You are working on it too. Wish we can find a good way to deal with query and MI. 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 >