From cbb09e6a75d8ff227a8ec6e57e43e5680bc1e4b6 Mon Sep 17 00:00:00 2001 From: Andrew Cagney Date: Fri, 31 May 2002 01:36:16 +0000 Subject: [PATCH] * gdbint.texinfo (Releasing GDB): Rename ``Obsoleting any code'' to ``Obsoleting code''. Revise. --- gdb/doc/ChangeLog | 5 +++++ gdb/doc/gdbint.texinfo | 51 +++++++++++++++++++++++++----------------- 2 files changed, 35 insertions(+), 21 deletions(-) diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 577ddb146bc..b7017158324 100644 --- a/gdb/doc/ChangeLog +++ b/gdb/doc/ChangeLog @@ -1,3 +1,8 @@ +2002-05-30 Andrew Cagney + + * gdbint.texinfo (Releasing GDB): Rename ``Obsoleting any code'' + to ``Obsoleting code''. Revise. + 2002-05-17 Jim Blandy * gdb.texinfo (C Preprocessor Macros): New chapter. diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index 4f76f5fb524..a8758745c49 100644 --- a/gdb/doc/gdbint.texinfo +++ b/gdb/doc/gdbint.texinfo @@ -5158,41 +5158,50 @@ This means that changes such as adding a new architectures or (within reason) support for a new host are considered acceptable.} -@section Obsolete any code +@section Obsoleting code Before anything else, poke the other developers (and around the source code) to see if there is anything that can be removed from @value{GDBN} (an old target, an unused file). Obsolete code is identified by adding an @code{OBSOLETE} prefix to every -line. Doing this means that it is easy to identify obsolete code when -grepping through the sources. +line. Doing this means that it is easy to identify something that has +been obsoleted when greping through the sources. -The process has a number of steps and is intentionally slow --- this is -to mainly ensure that people have had a reasonable chance to respond. -Remember, everything on the internet takes a week. +The process is done in stages --- this is mainly to ensure that the +wider @value{GDBN} community has a reasonable opportunity to respond. +Remember, everything on the Internet takes a week. -@itemize @bullet +@enumerate @item -announce the change on @email{gdb@@sources.redhat.com, GDB mailing list} +Post the proposal on @email{gdb@@sources.redhat.com, the GDB mailing +list} Creating a bug report to track the task's state, is also highly +recommended. @item -wait a week or so +Wait a week or so. @item -announce the change on @email{gdb-announce@@sources.redhat.com, GDB -Announcement mailing list} +Post the proposal on @email{gdb-announce@@sources.redhat.com, the GDB +Announcement mailing list}. @item -wait a week or so +Wait a week or so. @item -go through and edit all relevant files and lines (e.g., in -@file{configure.tgt}) so that they are prefixed with the word -@code{OBSOLETE}. -@end itemize +Go through and edit all relevant files and lines so that they are +prefixed with the word @code{OBSOLETE}. +@item +Wait until the next GDB version, containing this obsolete code, has been +released. +@item +Remove the obsolete code. +@end enumerate + +@noindent +@emph{Maintainer note: While removing old code is regrettable it is +hopefully better for @value{GDBN}'s long term development. Firstly it +helps the developers by removing code that is either no longer relevant +or simply wrong. Secondly since it removes any history associated with +the file (effectively clearing the slate) the developer has a much freer +hand when it comes to fixing broken files.} -@emph{Maintainer note: Removing old code, while regrettable, is a good -thing. Firstly it helps the developers by removing code that is either -no longer relevant or simply wrong. Secondly since it removes any -history associated with the file (effectively clearing the slate) the -developer has a much freer hand when it comes to fixing broken files.} @section Before the Branch -- 2.30.2