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: "Dave Korn" <dk at artimi dot com>
- To: "'Joel Brobecker'" <brobecker at gnat 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 19:07:56 +0100
- Subject: RE: Discussion: Formalizing the deprecation process in GDB
> -----Original Message-----
> From: Joel Brobecker
> Sent: 07 October 2004 19:01
> 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.
Yeh, of course, and being a relative newbie, it's hard for me to tell how
much (if any) of the difficulty I face is down to not having the right
balance (or just not enough docs), and how much of it is just inevitable
learning curve stuff.
> 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.
Erm... things that get deprecated don't often get un-deprecated, do they?
Wouldn't it largely be a matter of just adding a couple of lines each time
something gets deprecated, just enough to say "All this stuff is now
replaced by the new XXXX mechanism; use XXXXX_do_whatever in place of
deprecated_OLDXXXXXX_do_somethingelse, or see gdb-XXXXX.h for more
information." Or words to that effect. Shouldn't it be possible for the
old entries in that document to then remain more or less static? I'm
envisaging something that's a bit like a specialized changelog, but rather
than file-by-file and function-by-function descriptions of changes, which
are a bit low-level, it would have a list of deprecated functionalities and
their replacements.
cheers,
DaveK
--
Can't think of a witty .sigline today....