This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
[gdb-7.0 release] 2009-09-02 status and proposed plan
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb at sourceware dot org
- Date: Wed, 2 Sep 2009 09:44:25 -0700
- Subject: [gdb-7.0 release] 2009-09-02 status and proposed plan
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