From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24579 invoked by alias); 9 Jul 2008 22:19:02 -0000 Received: (qmail 24552 invoked by uid 22791); 9 Jul 2008 22:19:01 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_20,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; Wed, 09 Jul 2008 22:18:43 +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 m69MIfVn012096 for ; Wed, 9 Jul 2008 18:18:41 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m69MIesi025935; Wed, 9 Jul 2008 18:18:40 -0400 Received: from opsy.redhat.com (vpn-10-113.bos.redhat.com [10.16.10.113]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m69MIdka006513; Wed, 9 Jul 2008 18:18:39 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 451EF37829C; Wed, 9 Jul 2008 16:18:39 -0600 (MDT) To: Frysk List Subject: Changes From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Wed, 09 Jul 2008 22:19:00 -0000 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00011.txt.bz2 Here's the first message of the messages I promised during the meeting. Red Hat is revisiting its interest in Frysk. In particular, our goal is now: Build the best C++ debugger in the world. This has a few sub-goals: * Have a CLI * Integrate with Eclipse * Scale to very large programs (w/ lots of shared libraries) * Scale to many threads In particular I think Red Hat is not going to pursue Frysk's current monitoring and tracing goals, or the existing GUI. I'm sending everything in this message to this list. However, if the consensus is that we need a new list, that would also be fine by me. Meanwhile I'll carry on here. Internally we've revisited a number of decisions made during the course of Frysk's development. I'll summarize here our current thinking about what we'd like to do. Comments, criticism, etc are welcome. Note that I'm using the Red Hat "we" in the below. I'm sure that individuals disagree with various statements here. (Feel free to speak up, etc.) I am responsible for anything you read here, and I don't want to avoid that, but I did not want to take undue credit for ideas, etc, which are not mine. * 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. * 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. 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++. * 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. 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. * 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. * 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. * 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. * 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. 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. * Licensing. We discussed this at the meeting. Eric is looking into the ownership issue and the choice of license. 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? * 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.) * 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? That is pretty concise. I'm happy to try to expand on anything that seems unclear -- goals, reasoning, etc. I don't think I've forgotten anything here, but if I did, please bring it up. 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. thanks, Tom