* gdbint.texinfo (Releasing GDB): Revise the section `Before the

Branch'.

2 files changed, 29 insertions, 39 deletions

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index d7165c174c2..1d23b99fb74 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,8 @@
+2002-03-27  Andrew Cagney  <ac131313@redhat.com>
+
+	* gdbint.texinfo (Releasing GDB): Revise the section `Before the
+	Branch'.
+
 2002-03-18  Andrew Cagney  <ac131313@redhat.com>
 
 	* gdb.texinfo: Change all examples to @smallexample.
diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo
index f21721d30d4..c4c439dc44d 100644
--- a/gdb/doc/gdbint.texinfo
+++ b/gdb/doc/gdbint.texinfo
@@ -4989,7 +4989,8 @@ 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
+
+@section Before the Branch
 
 The most important objective at this stage is to find and fix simple
 changes that become a pain to track once the branch is created.  For
@@ -4997,34 +4998,17 @@ instance, configuration problems that stop @value{GDBN} from even
 building.  If you can't get the problem fixed, document it in the
 @file{gdb/PROBLEMS} file.
 
-@subheading Organize and announce the schedule.
+@subheading Prompt for @file{gdb/NEWS}
 
-The following is a possible schedule.  It is based on the rule-of-thumb
-that everything on the Internet takes a week.  You may want to even
-increase those times further since an analysis of the actual data
-strongly suggests that the below is far to aggressive.
+People always forget.  Send a post reminding them but also if you know
+something interesting happened add it yourself.  The @code{schedule}
+script will mention this in its e-mail.
 
-@itemize @bullet
-@item
-announce it
-@item
-wait a week
-@item
-announce branch date
-@item
-wait a week
-@item
-Cut the branch
-@item
-wait a week
-@item
-start enjoying all the fun
-@end itemize
+@subheading Review @file{gdb/README}
 
-As an aside, the branch tag name is probably regrettable vis:
-@smallexample
-gdb_N_M-YYYY-MM-DD-@{branch,branchpoint@}
-@end smallexample
+Grab one of the nightly snapshots and then walk through the
+@file{gdb/README} looking for anything that can be improved.  The
+@code{schedule} script will mention this in its e-mail.
 
 @subheading Refresh any imported files.
 
@@ -5034,27 +5018,28 @@ A number of files are taken from external repositories.  They include:
 @item
 @file{texinfo/texinfo.tex}
 @item
-@file{config.guess} et.@: al.@: 
+@file{config.guess} et.@: al.@: (see the top-level @file{MAINTAINERS}
+file)
+@item
+@file{etc/standards.texi}, @file{etc/make-stds.texi}
 @end itemize
 
-and should be refreshed.
+@subheading Check the ARI
 
-@subheading Prompt for @file{gdb/NEWS}
+@uref{http://sources.redhat.com/gdb/ari,,A.R.I.} is an @code{awk} script
+(Awk Regression Index ;-) that checks for a number of errors and coding
+conventions.  The checks include things like using @code{malloc} instead
+of @code{xmalloc} and file naming problems.  There shouldn't be any
+regressions.
 
-People always forget.  Send a post reminding them but also if you know
-something interesting happened add it your self.
+@subsection Review the bug data base
 
-@subheading Review @file{gdb/README}
+Close anything obviously fixed.
 
-Grab one of the nightly snapshots and then walk through the
-@file{gdb/README} looking for anything that can be improved.
+@subsection Check all cross targets build
 
-@subheading Check the ARI
+The targets are listed in @file{gdb/MAINTAINERS}.
 
-ARI is an @code{awk} script (Awk Regression Indicator?) that checks for a
-number of errors and coding conventions.  The checks include things like
-using @code{malloc} instead of @code{xmalloc} and file naming problems.
-There shouldn't be any regressions.
 
 @section Cut the branch