This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Discussion: Formalizing the deprecation process in GDB
- From: Joel Brobecker <brobecker at gnat dot com>
- To: Dave Korn <dk at artimi dot com>
- Cc: 'Andrew Cagney' <cagney at gnu dot org>, 'Eli Zaretskii' <eliz at gnu dot org>,gdb at sources dot redhat dot com
- Date: Thu, 7 Oct 2004 11:01:21 -0700
- Subject: Re: Discussion: Formalizing the deprecation process in GDB
- References: <416562C9.90801@gnu.org> <NUTMEGYiufL0xJdQdSe00000308@NUTMEG.CAM.ARTIMI.COM>
> > A running joke between several of the GDB developers at the last GCC
> > summit was that we should present a 1hr paper titled "porting
> > GDB to a
> > new architecture". Only instead of presenting slides, we'd
> > just write the code.
>
> I find it hard to believe that's possible for anyone who comes to
> the code from fresh. You have spent years working with gdb and have
> the advantage of knowing your way round the code, and what the
> replacements for each deprecated thing are; anyone else has to do
> lots of research. If there's going to be a formalization of the
> deprecation process, my 'feature request' would be that there be one
> single central place where all deprecated features are listed
> together with brief pointers to the new functionality that has taken
> their place.
Yes, it would be hard for a newbie to port GDB to a different
architecture in an hour. Or I'd be very impressed :-).
Anyway, like in any project, there is a learning curve, and that
curve can be reduced to a certain degree by good documentation.
However, you have to balance the amount of document your write
and *maintain* with the amount of work this saves for some potential
contributor. I think that maintaining the list of deprecated features
in a separate document is going to be a large amount of work.
GDB is changing so fast. It's simpler to put that information directly
in the code, and most of the time, the information is actually already
there.
I have to say that GDB's learning curve is not that steep, compared
to other projects I have worked on. You don't necessarily need to
grab the whole picture before you can actually start working effectively
on it. I have been contributing to GDB for several years now, and
I honestly still think that I don't have a complete global view of
GDB yet. Some areas I know very well, I have a rough idea of the major
components, how they interact, but some important areas are still
unexplored territory. If I had this global view, I think I could
be promoted as global maintainer :-).
--
Joel