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

[Hui Zhu <teawater at gmail dot com>]

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
>