This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Re: Changes
- From: Sami Wagiaalla <swagiaal at redhat dot com>
- To: tromey at redhat dot com
- Cc: Frysk List <frysk at sourceware dot org>
- Date: Wed, 09 Jul 2008 20:06:14 -0400
- Subject: Re: Changes
- References: <m33ami66rk.fsf@fleche.redhat.com>
* HPD. We discussed HPD a little. It seems ok, overall, though a bit
underpowered; in particular there are common debugging operations
that one can do in gdb which have no analog in HPD. So, we know we
must at least extend it.
Some people expressed concern that the HPD language differs
needlessly from gdb -- meaning that they need to re-learn things to
try a new debugger. I don't think we have a particular solution in
mind for this. We could move more toward a gdb-like CLI, or we
could supply a compatibility mode; dunno.
I think neither GDB nor the HPD spec should be taken literary we can use
them as a source of inspiration. HPD offers cool commands like focus
because it has considered the multi threaded, multi process problem. GDB
offers familiarity.
* 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.
Having written a gui at once before has served the great purpose of
making sure that the design of the core is gui friendly. Things like
asynchronous requests, and top/bottom half event handling. So I think we
know what it takes to write a gui friendly core and we can get away with
not writing one for a while.
* Naming. There's some contention as to whether the result should
keep the name "Frysk". I will let proponents and opponents make
their arguments; I don't have an opinion on this.
I vote -1 on this. The frysk brand is a good one and can now be made
even better. Adoppting a new one will make the frysk brand look bad, and
the new one look untrustworthy. Also, I think it is not needed as the
goals of the project have not changed in my opinion, but repriorities,
or better communicated. things like lots of threads lots of .so's have
been on our tongues for a while.
* 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 am ambivalent about this, but i will vote +1 because i would like to
try it out and see if it improves ownership, and familiarity with parts
of the code other than what one is working on.
* 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.
We havent done it publicly before. Lets do it and see how it works out.
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.
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.
I am a fan of time based releases. If i was to run the project I would
give people 3 week assignments (or 3 months assignments that can be
broken into 3 week deliverables) and do a monthly release. At this point
however, as the project is accelerating from 0, i dont know what makes
sence. Maybe quarterly releases.
* 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?
I would choose to not work on GDB. I think it would be difficult to get
our patches upstream especially ones as radical as we will propose, and
rightly so. If you send a patch to gdb that implements a thread state
machine for example, how would gdb maintainers know what effect this has
on all the permutations of archetecutre, language, and executable
formats that gdb supports ?
Any points which I have not responded to I have no objects or comments on.
Sami