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

[Hui Zhu]

Hi Joel,

Thanks for your work.

Gdb-cvs-head have a build error in cygwin with "--enable-targets=all
--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<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
>