[gdb-7.0 release] 2009-09-02 status and proposed plan

[Marc Khouzam]

Oh yeah, and there's the Reverese MI patches that would be nice to have
in 7.0.  I believe everything was approved but it is delayed by
the assignment.  I guess there's nothing to do about that
until the legal stuff is resolved.  Hopefully it can be
accepted after the branch.

Just it's not forgotten :-)

I believe the approvals are below by Eli and Volodya
http://sourceware.org/ml/gdb-patches/2009-09/msg00050.html
http://sourceware.org/ml/gdb-patches/2009-09/msg00051.html

http://sourceware.org/ml/gdb-patches/2009-08/msg00512.html
http://sourceware.org/ml/gdb-patches/2009-08/msg00534.html

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Hui Zhu
> Sent: Wednesday, September 16, 2009 2:47 AM
> To: Joel Brobecker
> Cc: gdb@sourceware.org; Michael Snyder
> Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan
> 
> 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 <on|off>
> 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 
> <brobecker@adacore.com> 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:
> >
> >  (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
> >
>