Re: Changes

[Sami Wagiaalla <swagiaal@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