Re: Move GDB to C++ ?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 1 Aug 2008 09:13:12 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <vladimir@codesourcery.com>, gdb@sources.redhat.com
> 
> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
> > > From:  Vladimir Prus <vladimir@codesourcery.com>
> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
> > > 
> > > I think this discussion went a bit wrong way -- trying to convince folks that
> > > *investing effort* in converting to C++ is justified. However, I don't think
> > > the proposal is about making folks not interested in C++ doing any work -- the
> > > proposal is about allowing folks who do some specific work, and want to make
> > > use of additional features C++ provides, to use those features, while not imposing
> > > significant problems on the rest of contributors.
> > 
> > Your being busy refactoring does impose a significant problem on me.
> > We are members of the same team, so how you use your time while on the
> > team is important to me.
> 
> Could you please expand on this idea?

The idea is that a maintainer cannot behave with the code as he
pleases, claiming that it's his time and therefore his, and only his,
business.

The idea is also that GDB is a collective effort, so arguments saying
"I will do this because I like it, and you shouldn't care" are not
something I'm willing to accept.

> GDB is a GNU project, driven by volunteers and sponsored contributors.
> And the sponsored contributors are volunteers from the perspective of
> anyone outside the sponsoring organization.  I don't understand the
> objection to other people choosing to invest effort on something, even
> if you think it's unimportant.  Volunteer projects go where their
> volunteers want to take them!

We are not talking about just any change here.  We are talking about a
change that will affect everyone.  Taking a volunteer project in such
directions without consensus isn't right, IMO.  Vladimir's message in
effect tried to side-step the lack of consensus, which is not how I
thought GDB development should advance.

> And I think one of the bit structural issues in GDB is that it's hard
> for even active volunteers to take it to new places.  I want to make
> that easier.

So do I, but what new places are we talking about?  Until now, I fail
to see even a single direction in which someone would like to go,
while the fact that GDB is written in C makes that hard.