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

[Joel Brobecker <brobecker at adacore dot com>]

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