From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10455 invoked by alias); 10 Jul 2008 00:06:46 -0000 Received: (qmail 10448 invoked by uid 22791); 10 Jul 2008 00:06:45 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jul 2008 00:06:23 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6A06LJE009907 for ; Wed, 9 Jul 2008 20:06:21 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6A06LpN015754; Wed, 9 Jul 2008 20:06:21 -0400 Received: from localhost.localdomain (vpn-12-6.rdu.redhat.com [10.11.12.6]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6A06Jhs002242; Wed, 9 Jul 2008 20:06:19 -0400 Message-ID: <48755276.2020801@redhat.com> Date: Thu, 10 Jul 2008 00:06:00 -0000 From: Sami Wagiaalla User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: tromey@redhat.com CC: Frysk List Subject: Re: Changes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00012.txt.bz2 > * 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