From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6230 invoked by alias); 14 Jul 2008 16:58:47 -0000 Received: (qmail 6218 invoked by uid 22791); 14 Jul 2008 16:58:46 -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; Mon, 14 Jul 2008 16:58:27 +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 m6EGwOaa013711; Mon, 14 Jul 2008 12:58:24 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6EGwOe2026150; Mon, 14 Jul 2008 12:58:24 -0400 Received: from localhost.localdomain (vpn-4-54.str.redhat.com [10.32.4.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6EGwMXc030457; Mon, 14 Jul 2008 12:58:22 -0400 Message-ID: <487B85AD.30606@redhat.com> Date: Mon, 14 Jul 2008 16:58:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Tom Tromey , Frysk List Subject: Re: Roadmap beginnings References: <20080711215243.GA30836@caradoc.them.org> <20080714164531.GA6283@caradoc.them.org> In-Reply-To: <20080714164531.GA6283@caradoc.them.org> Content-Type: text/plain; charset=us-ascii; 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/msg00034.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Jul 14, 2008 at 10:33:48AM -0600, Tom Tromey wrote: > >> Thanks in particular for your comments on the particular C++ work >> items. Yes thanks, good to have as much input at possible. >> I think those combined form a pretty powerful argument. >> There's still some unaddressed though: >> >> * Multi-process. I've seen some hints on the list that this is >> coming, but not enough info to really understand. This seems like >> something that would affect many areas -- there would seem to be >> challenges from the CLI on down. >> > > Yes. I can say that CodeSourcery is working on this, and I fully > expect to have an implementation posted by ... say ... mid-October. > Focus is likely to be on MI, though it will certainly be somehow > CLI-accessible. We plan to do the work (or at least the design) in > public; if anyone wants to help... > Being a definite newbie to GDB, how does the community reconcile the multiple and large changes that are being discussed, and implement them into a stable release base? To an outsider they all seem to be converging at once. I know "move to C++" and "multi-process" are orthogonal, but they have to exist in the same working code-base. If the C++ stuff happens, and it just so happens this new multi-process functionality is introduced, what then? Will C "only" patches be discouraged? These questions might be better suited to the the GDB list, in fact, but I'm curious with all these changes how they will be managed. > One thing that might benefit GDB is for someone to sit down and come > up with a few new-approach-to-debugging features like these. Stick > them up on the wiki or something... > > A nice thing about new features is that they're shiny, a.k.a. a good > draw-in for new contributors. > When one implements a new feature that has architecture specific components, is it the job of the new feature-implementer to implement these for as many architectures as possible? Does he champion the cause of other folk to go ahead and contribute for their chosen architecture? Or is it more of an approach of: "Here is a new feature, this is the architecture I implemented it on, lets review if it can work for others?" Regards Phil