public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@br.ibm.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Frysk List <frysk@sourceware.org>
Subject: Re: Changes
Date: Thu, 10 Jul 2008 04:17:00 -0000	[thread overview]
Message-ID: <1215663421.5233.33.camel@localhost.localdomain> (raw)
In-Reply-To: <m33ami66rk.fsf@fleche.redhat.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

  parent reply	other threads:[~2008-07-10  4:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-09 22:19 Changes Tom Tromey
2008-07-10  0:06 ` Changes Sami Wagiaalla
2008-07-11 17:04   ` Changes Sami Wagiaalla
2008-07-10  4:17 ` Thiago Jung Bauermann [this message]
2008-07-10  5:43   ` Changes Sami Wagiaalla
2008-07-10 13:14     ` Changes Rick Moseley
2008-07-10 13:26       ` Changes Phil Muldoon
2008-07-10 17:07       ` Changes Eric Bachalo
2008-07-10 19:43   ` Changes Dodji Seketeli
2008-07-11 16:55   ` Changes Tom Tromey
2008-07-10  8:24 ` Changes Phil Muldoon
2008-07-11 10:44 ` Changes Phil Muldoon
2008-07-17  7:51 ` Changes Jan Blunck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1215663421.5233.33.camel@localhost.localdomain \
    --to=bauerman@br.ibm.com \
    --cc=frysk@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).