public inbox for
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <>
To: Phil Muldoon <>
Cc: Tom Tromey <>, Frysk List <>
Subject: Re: Roadmap beginnings
Date: Mon, 14 Jul 2008 17:09:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jul 14, 2008 at 05:58:21PM +0100, Phil Muldoon wrote:
> 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.

The history of the GDB community is such that it's not used to this
degree of progress :-)  We're feeling our way along.  The community
has experienced a huge surge in development activity over the past ~

As for C++, I'm not yet holding my breath.  But if the transition does
come to pass, the individuals driving it will have to come up with a
plan to not disrupt everyone else's work unduly.  C to C++ has some
advantages in this respect over other language transitions.

> 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?"

Again, it's not like the GDB community has policies on this sort of
thing - it's a very loosely structured group.  My personal position is
that new features should be implemented in ways that do not
unnecessarily restrict support for other platforms, but if platform
specific work is necessary and the feature is shiny enough, platform
maintainers will fill it in of their own accord.

Daniel Jacobowitz

  reply	other threads:[~2008-07-14 17:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 19:53 Tom Tromey
2008-07-11 20:56 ` Jan Kratochvil
2008-07-11 21:37   ` Tom Tromey
2008-07-11 21:54     ` Daniel Jacobowitz
2008-07-11 23:11   ` Kris Van Hees
2008-07-11 21:53 ` Daniel Jacobowitz
2008-07-14 16:34   ` Tom Tromey
2008-07-14 16:45     ` Daniel Jacobowitz
2008-07-14 16:58       ` Phil Muldoon
2008-07-14 17:09         ` Daniel Jacobowitz [this message]
2008-07-14 17:19     ` Ian Lance Taylor
2008-07-14 17:34       ` Daniel Jacobowitz
2008-07-14 18:04         ` Tom Tromey
2008-07-14 18:12           ` Daniel Jacobowitz
2008-07-14 18:11         ` Ian Lance Taylor
2008-07-14 17:35       ` Tom Tromey
2008-07-14 18:13         ` Ian Lance Taylor
2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
2008-07-11 22:48 ` Roadmap beginnings Phil Muldoon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).