Tasks

[Tom Tromey <tromey at redhat dot com>]

I started to look at breaking down the roadmap into discrete tasks.
Here's a rough draft.  It is a bit concise since the initial tasks
have are investigatory... IMO we need to know a bit more and should
try to get some rough estimates on them so we can clump them into
milestones.

* Administrative
  - Set up bugzilla
  - Set up git
  - Set up auto-builder and patch tester.
    BTW we can use the GCC Compile Farm for this if we like.

  The first two are actual tasks, I'll do those.
  The third one I can do, too, unless somebody is eager to do it.

* Expression parsing.

  I think the first thing here is a good look at what we should aim to
  do.  Should we try to fix bugs?  Or try for the full implementation?
  Or both in parallel?  If we're fixing bugs, what kind of thing are
  we unlikely to be able to fix?  If the full implementation, how big
  a job is that really?  In both cases, what dependencies do we have
  on gcc?

  This is probably the single biggest item.
  Maybe a couple people should look at this..?

* Exceptions.  Look at the existing longjmp stuff, come up with an
  estimate for the new work.  Also look at the current state of the
  various "catch" commands, maybe look though gnats to see if anything
  is known to be broken.

* Pretty-printing.  My plan here has been:
  - Merge in the existing python work
  - Make it possible to associate a 'struct type' with a given Python
    object, in the non-MI case (the MI case is already in
    there... FWIW we'd want to use the same Python objects to handle
    both cases).
  - Update 'print' to use this object if it exists
  - Add 'print/r' (r == 'raw') to bypass the pretty-printer
  - Write a bunch of pretty-printers for libstdc++.  There are some
    good examples to start from (some on the wiki)

  So, for estimation we need to look at the size of some of these
  parts, and also whether anything is missing.

* Smarter demangling.  Figure out what this really means :).  Look in
  gdb bugzilla for info.  Write some test cases.  Look at gcc
  dependencies.

* Scalability and shared libraries.  Profile some examples.  Figure
  out what is wrong.  Jan has some information here.

* Froggy.  IMO too early to start looking at this for gdb... Chris,
  Phil, Roland -- do you agree?

* GCC changes.  I think the task list here should come from the above.
  But, once we have that list of dependencies it would be worth making
  another pass through GCC bugzilla to see what we are missing.  So,
  we can leave this one for a bit.

* Fedora patches.  I think we can look at this as a case of patch
  review... comments on this?  So, no immediate investigation to do.

* For scripting and write-it-in-C++, I don't think we need to do
  anything right away.


So, I think everybody should take an item, send a note to the list
about which you are going to do, and then later send a note about the
outcome -- a rough idea of what is involved, how big the changes are,
etc.

These estimates are just to help guide us in scheduling things.  Given
that and our general newness to gdb, I would say give them a one month
granularity.

I'll take whatever task nobody else wants.

thanks,
Tom