Re: Changes

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

Hi,

My R$ 0,02 FWIW.

On Wed, 2008-07-09 at 16:18 -0600, Tom Tromey wrote:
> Here's the first message of the messages I promised during the
> meeting.

Thanks.

> * Integrate with Eclipse

The debugger being in C++, do you see this happening with an MI-like
interface?

> In particular I think Red Hat is not going to pursue Frysk's current
> monitoring and tracing goals, or the existing GUI.

Perhaps this can be left as a dormant goal, to be revisited when a
working solution is at hand?

A monitoring and tracing tool would be very useful.

> * Java.  We've heard many times while discussing Frysk with other
>   parties that the choice of Java is an odd one.
> 
>   In order to more fully align the interests of the developers of the
>   debugger with the interests of its users, we'd like to use C++ as
>   the implementation language.  We picture refactoring the core of
>   Frysk into C++; not changing the design but simply the
>   implementation language.

Nice. IMHO, starting from scratch again in C++ would be just more work
at the end of the day... IMHO again the way to go is to reuse as much
code as possible, including from GDB. The idea is to take the shortest
path to a good working solution.

> * Scripting.  One issue with gdb is its poor support for scripting.
>   We think scripting is needed for debugger programmability, and in
>   particular that it will be needed for C++ pretty-printing.  So, our
>   thinking is that this debugger would have a Python binding to its
>   core.

I'm in favour of that.
I just think that poor support for scripting shouldn't be counted as a
weakness of GDB, since it is being addressed there as we speak (of
course you know that :-) ).

>   In order to exercise this binding code, we picture rewriting the
>   existing CLI code in Python.  The idea here is that part of the CLI
>   need a rewrite anyhow, and there is no particular reason that the
>   CLI needs to be written in C++.

Nice idea.

>   We think it makes sense to still have a CLI even though there is
>   also a scripting language under the hood.  The reason for this is
>   simply that Python would make for a funny CLI -- you'd have to quote
>   arguments, etc.

Agreed.

> * We would like to drop the existing GUI.  It does not align with our
>   goals.  However, as I said during the meeting, if someone wants to
>   maintain the GUI, that would be fine.
> 
>   We may want a standalone debugger GUI.  One idea is to see if we can
>   reuse the Eclipse work using RCP.  Another idea is to go the gdb
>   route and hope some 3rd party either writes one, or ports and
>   existing one from gdb.

So having a GUI separate from Eclipse is within the goal of the project?
Just not the existing one? Sorry, I'm not sure I understood this part.

> * Process.  We'd like to institute some form of patch review.  Ideally
>   this would be low on bureaucracy; perhaps just an Apache-style "+1"
>   voting system.  The intent here is to raise coding standards overall
>   -- make sure that features have more polish when they go in, and
>   that both internal and external documentation are included.

I like the idea of a patch review process, I agree it will be a benefit.

> * Roadmap and milestones.  We want to publish a general roadmap along
>   with milestones that will describe roughly what features will be
>   available when.  I don't know whether this is interesting to non-Red
>   Hat folks; if not we can do this internally.  Let us know.

Please, don't have internal milestones, and avoid as much as possible
having internal anything... This is a very important point in trying to
make this a community project and not just a Red Hat one.

I think it is important for non-Red Hat folks to know what Red Hat
people are working at, and what are your goals, even short term ones.

>   The general milestone idea we've been discussing is "depth first" --
>   using user-visible features to drive the development process; but
>   probably the "releases" would be time-based as much as possible.

Sounds good.

>   The roadmap will be where we figure out what "best C++ debugger"
>   means -- that is, what specific features this entails.  We'll be
>   starting that process on this list (or elsewhere in public) soon.

Look forward to it.

> * Licensing.  We discussed this at the meeting.  Eric is looking into
>   the ownership issue and the choice of license.

This is another very important point ïin trying to make this a community
project and not just a Red Hat one.

Having Red Hat own all the code is a big road block to community
participation.

>   We've talked a bit about constraints on the license and owner:
> 
>   * Who owns the current code; what do we need to drop or relicense if
>     we want to change the license
>   * Can we assign to the FSF or some other entity?

That's an interesting option.

>   * What constraints does our Eclipse integration approach put on the
>     choice?  Rick is looking into some details here.
>   * Can we reuse bits of gdb if we want?  (There are a few things that
>     might be worth reusing.)

As I said, IMHO we should reuse bits of GDB, and the licensing choice
should not hinder it.

> * GDB.  A recurring question is: why not expend our efforts improving
>   gdb?  There are no easy answers here; the tradeoffs are complicated.
> 
>   This is probably more of a Red Hat internal decision (it is about
>   where we want to focus our efforts, not about the frysk project per
>   se) -- but it is an obvious and important question and deserves to
>   be brought up here.
> 
>   We're open to arguments either way on this topic.  Given our goals,
>   what would you choose to do?

Like I said in the meeting, I'd choose to improve GDB. Of course I'm
nowhere near experienced enough in GDB to evaluate all the risks and
difficulties with that, but from where I stand it is the option that
makes more sense from a technical standpoint, and that would give the
biggest bang for the buck. Again, I'm thinking in terms of the shortest
path to get to a good solution.

> Since we want to build a healthy community around this project, your
> opinion matters.  Please share it.  Aside from Red Hat's goals,
> nothing here is truly decided; it is all open to debate.

Great. That's nice to know.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center