This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion: Formalizing the deprecation process in GDB


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]