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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel>   (b) Rename the python-support files to be 8.3-compliant.
Joel>       I thought that the change had been approved, but I see that
Joel>       the change has not been made.  Has it been approved? If yes,
Joel>       it is being held up because we don't know how to best rename
Joel>       files without disturbing git?

I'm ok with the simple rm + add approach.  This has the advantage of not
requiring anybody to log into sourceware and monkey around with the
repository.  One thing that has factored into my thinking here is that
there have not been many revisions to these files in gdb CVS.  So,
trying to preserve the history in a super-convenient form is not
extremely important.  On the off chance that somebody needs the older
history they can just "cvs log" the old file names.

Joel>   (c) varobj support for Python pretty-printing
Joel>       Tom gave a quick status on IRC yesterday. It sounds like
Joel>       there isn't much left to do. Perhaps a quick update on the Wiki
Joel>       page to state exactly what's left would be nice.  Unless fixing
Joel>       the last thing or two might be faster ;-).

There's one more bug.  Of course, there's only been one more bug for the
last 4 weeks :-(

I plan to do the work to merge this to trunk this week.

Joel>   (f) bug in breakpoint commands: commands not evaluated outside of
Joel>       main command loop.
Joel>       http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html
Joel>       There is a suggested patch, but needs looking at. Any taker?

There are a number of other unreviewed patches.  I can try to make a
list if that would be helpful.

I would like us to commit to reviewing all patches that arrived before
some cutoff date before the release.  I think this is important to
encourage continued contributions to GDB.  Also, I consider this part of
our duty as maintainers.

I don't have a proposal for when this cutoff should be, but I think it
should be in the future.  (It could be the very near future.)

Joel> If there are any issue that you know of that are *RELEASE-CRITICAL*
Joel> (build failure, regressions), please let us know

I have a couple more, I'm afraid.

I think the "Fix Darwin breakage" and "Speed up find_pc_section" threads
need to reach some sort of resolution.  I haven't caught up on these
yet, so maybe these are already concluded.

Finally, I think we should get the DW_OP_*_value patch in.  This patch
is needed with GCC svn trunk, now that VTA has gone in.  (I'm working on
the final bit of this patch: the test cases.)

Joel> In terms of dates, I would like us to try to release sooner rather than
Joel> later. Can I suggest we try to shoot for Wed Sep 9th for the branch date,
Joel> and then try to release a couple of weeks after (that would be the 23rd)?

It seems possible, at least if people step up for the remaining tasks.

Joel> Also, it sounds like a lot more new features are currently being
Joel> developed, and people are trying to make it for 7.0. I propose to
Joel> release 7.1 not too long after 7.0: Instead of waiting 6 months,
Joel> we could release around end of January, early Feb (say: branch mid
Joel> Jan, release end of Jan).

I think that would be a good idea.

Tom