This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: build/917: Instructions for making gdb.tar.gz need update fornew makefile
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 9 Jan 2003 20:48:01 -0000
- Subject: Re: build/917: Instructions for making gdb.tar.gz need update fornew makefile
- Reply-to: Andrew Cagney <ac131313 at redhat dot com>
The following reply was made to PR build/917; it has been noted by GNATS.
From: Andrew Cagney <ac131313@redhat.com>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: nobody@sources.redhat.com, gdb-gnats@sources.redhat.com
Subject: Re: build/917: Instructions for making gdb.tar.gz need update for
new makefile
Date: Thu, 09 Jan 2003 15:45:12 -0500
This is a multi-part message in MIME format.
--------------070403000308090609080302
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
WIP attached.
--------------070403000308090609080302
Content-Type: text/plain;
name="diffs"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="diffs"
? diffs
? wip-gdbint.texinfo
Index: gdbint.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.100
diff -u -r1.100 gdbint.texinfo
--- gdbint.texinfo 24 Aug 2002 00:21:37 -0000 1.100
+++ gdbint.texinfo 9 Jan 2003 20:44:29 -0000
@@ -24,7 +24,7 @@
Software Foundation raise funds for GNU development.''
@end ifinfo
-@setchapternewpage off
+@c @setchapternewpage off
@settitle @value{GDBN} Internals
@syncodeindex fn cp
@@ -1411,7 +1411,7 @@
obtain various status values from @value{GDBN}.
@end itemize
-Since @code{libgdb} could have multiple clients (e.g. a GUI supporting
+Since @code{libgdb} could have multiple clients (e.g., a GUI supporting
the existing @value{GDBN} CLI), those clients must co-operate when
controlling @code{libgdb}. In particular, a client must ensure that
@code{libgdb} is idle (i.e. no other client is using @code{libgdb})
@@ -1559,7 +1559,7 @@
@code{@var{xyz}_sym_init} for possible initialization. @code{addr} is
the offset between the file's specified start address and its true
address in memory. @code{mainline} is 1 if this is the main symbol
-table being read, and 0 if a secondary symbol file (e.g. shared library
+table being read, and 0 if a secondary symbol file (e.g., shared library
or dynamically loaded file) is being read.@refill
@end table
@@ -1633,16 +1633,16 @@
@findex find_pc_function
@findex find_pc_line
@item
-By its address (e.g. execution stops at some address which is inside a
-function in this file). The address will be noticed to be in the
-range of this psymtab, and the full symtab will be read in.
+By its address (e.g., execution stops at some address which is inside a
+function in this file). The address will be noticed to be in the range
+of this psymtab, and the full symtab will be read in.
@code{find_pc_function}, @code{find_pc_line}, and other
@code{find_pc_@dots{}} functions handle this.
@cindex lookup_symbol
@item
By its name
-(e.g. the user asks to print a variable, or set a breakpoint on a
+(e.g., the user asks to print a variable, or set a breakpoint on a
function). Global names and file-scope names will be found in the
psymtab, which will cause the symtab to be pulled in. Local names will
have to be qualified by a global name, or a file-scope name, in which
@@ -4246,19 +4246,19 @@
implementations simply locate the registers themselves.@refill
@end table
-When making @value{GDBN} run native on a new operating system, to make it
-possible to debug core files, you will need to either write specific
+When making @value{GDBN} run native on a new operating system, to make
+it possible to debug core files, you will need to either write specific
code for parsing your OS's core files, or customize
@file{bfd/trad-core.c}. First, use whatever @code{#include} files your
machine uses to define the struct of registers that is accessible
(possibly in the u-area) in a core file (rather than
@file{machine/reg.h}), and an include file that defines whatever header
-exists on a core file (e.g. the u-area or a @code{struct core}). Then
+exists on a core file (e.g., the u-area or a @code{struct core}). Then
modify @code{trad_unix_core_file_p} to use these values to set up the
section information for the data segment, stack segment, any other
segments in the core file (perhaps shared library contents or control
information), ``registers'' segment, and if there are two discontiguous
-sets of registers (e.g. integer and float), the ``reg2'' segment. This
+sets of registers (e.g., integer and float), the ``reg2'' segment. This
section information basically delimits areas in the core file in a
standard way, which the section-reading routines in BFD know how to seek
around in.
@@ -5324,11 +5324,12 @@
@smallexample
make -f Makefile.in gdb.tar.gz
+
@end smallexample
@noindent
This will properly configure, clean, rebuild any files that are
-distributed pre-built (e.g. @file{c-exp.tab.c} or @file{refcard.ps}),
+distributed pre-built (e.g., @file{c-exp.tab.c} or @file{refcard.ps}),
and will then make a tarfile. (If the top level directory has already
been configured, you can just do @code{make gdb.tar.gz} instead.)
@@ -5395,61 +5396,97 @@
to @var{M}.@var{N}.0.90 (dot zero, dot ninety). Follow on releases have
an incremented minor minor version number (.0).
-Using 5.1 (previous) and 5.2 (current), the example below illustrates a
+Using 5.2 (previous) and 5.3 (current), the example below illustrates a
typical sequence of version identifiers:
@table @asis
-@item 5.1.1
+
+@item The 5.3 branch:
+@table @asis
+@item 5.2.1
final release from previous branch
-@item 2002-03-03-cvs
-main-line the day the branch is cut
-@item 5.1.90-2002-03-03-cvs
+@item 5.2.90-2002-03-03-cvs
corresponding branch version
-@item 5.1.91
+@item 2002-03-03-cvs
+auto-upated mainline for the same day
+@end table
+
+@item The first 5.3 draft release candidate:
+@table @asis
+@item 5.2.91
first draft release candidate
-@item 5.1.91-2002-03-17-cvs
+@item 5.2.91-2002-03-17-cvs
updated branch version
-@item 5.1.92
-second draft release candidate
-@item 5.1.92-2002-03-31-cvs
-updated branch version
-@item 5.1.93
+@item 2002-03-17-cvs
+auto-updated mainline for the same day
+@end table
+
+@item The final 5.3 release candidate:
+@table @asis
+@item 5.2.92
final release candidate (see below)
-@item 5.2
+@item 5.3
official release
-@item 5.2.0.90-2002-04-07-cvs
-updated CVS branch version
-@item 5.2.1
+@item 5.3.0.90-2002-04-07-cvs
+updated branch version
+@item 2002-04-07-cvs
+auto-updated mainline for the same day
+@end table
+
+@item First 5.3.1 re-release candidate:
+@table @asis
+@item 5.3.0.91
+first draft re-release candidate
+@item 5.3.0.91-2002-04-07-cvs
+updated branch version
+@item 2002-04-07-cvs
+auto-updated mainline for the same day
+@end table
+
+@item Final 5.3.1 re-release candidate:
+@table @asis
+@item 5.3.0.92
+final re-release candiate (see below)
+@item 5.3.1
second official release
+@item 5.3.1.90-2002-05-07-cvs
+updated branch version
+@item 2002-05-07-cvs
+auto-updated mainline for the same day
@end table
+@end table
+
+@noindent
Notes:
@itemize @bullet
@item
-Minor minor minor draft release candidates such as 5.2.0.91 have been
-omitted from the example. Such release candidates are, typically, never
-made.
+Minor minor minor draft re-release candidates such as 5.3.0.91 are,
+typically, never made.
+@item
+For 5.2.92 the bziped tar ball @file{gdb-5.2.92.tar.bz2} is just the
+official @file{gdb-5.3.tar} renamed and compressed.
+@item
+For 5.2.0.92 the bziped tar ball @file{gdb-5.2.0.92.tar.bz2} is just the
+official @file{gdb-5.3.1.tar} renamed and compressed.
@item
-For 5.1.93 the bziped tar ball @file{gdb-5.1.93.tar.bz2} is just the
-official @file{gdb-5.2.tar} renamed and compressed.
-@end itemize
-
To avoid version conflicts, vendors are expected to modify the file
@file{gdb/version.in} to include a vendor unique alphabetic identifier
(an official @value{GDBN} release never uses alphabetic characters in
its version identifer).
-
+@item
Since @value{GDBN} does not make minor minor minor releases (e.g.,
-5.1.0.1) the conflict between that and a minor minor draft release
-identifier (e.g., 5.1.0.90) is avoided.
+5.3.1.1) the conflict between that and a minor minor draft release
+identifier (e.g., 5.3.1.90) is avoided.
+@end itemize
@subsection Branches
-@value{GDBN} draws a release series (5.2, 5.2.1, @dots{}) from a single
+@value{GDBN} draws a release series (5.3, 5.3.1, @dots{}) from a single
release branch (gdb_5_2-branch). Since minor minor minor releases
-(5.1.0.1) are not made, the need to branch the release branch is avoided
+(5.2.0.1) are not made, the need to branch the release branch is avoided
(it also turns out that the effort required for such a a branch and
release is significantly greater than the effort needed to create a new
release from the head of the release branch).
@@ -5477,8 +5514,7 @@
@section Branch Commit Policy
-The branch commit policy is pretty slack. @value{GDBN} releases 5.0,
-5.1 and 5.2 all used the below:
+The branch commit policy is pretty slack.
@itemize @bullet
@item
@@ -5498,6 +5534,9 @@
Only post a proposal to change the core of @value{GDBN} after you've
sent individual bribes to all the people listed in the
@file{MAINTAINERS} file @t{;-)}
+@item
+Only the very brave or very foolish would try to apply the obvious fix
+rule to the branch.
@end itemize
@emph{Pragmatics: Provided updates are restricted to non-core
@@ -5566,25 +5605,42 @@
something interesting happened add it yourself. The @code{schedule}
script will mention this in its e-mail.
-@subheading Review @file{gdb/README}
+If it is a minor minor release (e.g., 5.3.1) do a quick diff against the
+previous release to determine what really changed.
+
+@subheading Prompt for testers.
-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.
+Send e-mail to @email{gdb-testers@@sources.redhat.com, GDB Testers
+mailing list} (cc'ing @email{gdb@@sources.redhat.com, GDB Discsussion
+mailing list}) prompting people to try downloading, building and testing
+a @value{GDBN} snapshot. Also mention the release cycle.
+
+@subheading Review @file{gdb/README} and the daily snapshot
+
+Grab one of the nightly snapshots and then walk through the file
+@file{gdb/README} firstly checking that the daily snapshot still builds
+and secondly seeing if anything can be improved.
+
+@emph{Maintainer note: The file @file{gdb/README} should be replaced
+with more generic install instructions that are generated from the
+documentation sources.}
@subheading Refresh any imported files.
A number of files are taken from external repositories. They include:
-@itemize @bullet
-@item
-@file{texinfo/texinfo.tex}
-@item
-@file{config.guess} et.@: al.@: (see the top-level @file{MAINTAINERS}
-file)
-@item
-@file{etc/standards.texi}, @file{etc/make-stds.texi}
-@end itemize
+@table @file
+@item texinfo/texinfo.tex
+See @url{ftp://ftp.gnu.org/pub/gnu/texinfo/}.
+@item config.guess
+@itemx config.sub
+See the top-level @file{MAINTAINERS} file.
+@item etc/standards.texi
+@itemx etc/make-stds.texi
+@c @itemx etc/maintain.texi
+Try @url{ftp://ftp.gnu.org/pub/gnu/standards/} but that copy proved more
+out-of-date than what was in @file{etc/}.
+@end table
@subheading Check the ARI
@@ -5594,6 +5650,12 @@
of @code{xmalloc} and file naming problems. There shouldn't be any
regressions.
+@subheading Update Makefile.in
+
+Once @value{GDBN} is converted to @code{automake} this can be dropped.
+
+It doesn't hurt to check the @file{Makefile.in} dependencies.
+
@subsection Review the bug data base
Close anything obviously fixed.
@@ -5608,25 +5670,24 @@
@subheading Create the branch
@smallexample
-$ u=5.1
-$ v=5.2
-$ V=`echo $v | sed 's/\./_/g'`
-$ D=`date -u +%Y-%m-%d`
-$ echo $u $V $D
-5.1 5_2 2002-03-03
-$ echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
--D $D-gmt gdb_$V-$D-branchpoint insight+dejagnu
-cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
--D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight+dejagnu
-$ ^echo ^^
-...
-$ echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
--b -r gdb_$V-$D-branchpoint gdb_$V-branch insight+dejagnu
+$ @kbd{u=5.2}
+$ @kbd{v=5.3}
+$ @kbd{V=`echo $v | sed 's/\./_/g'`}
+$ @kbd{D=2002-09-04}
+$ @kbd{echo $u $v $V $D}
+5.2 5.3 5_3 2002-09-04
+$ @kbd{echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \}
+> @kbd{-D $D-gmt gdb_$V-$D-branchpoint insight+dejagnu}
+cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
+-D 2002-09-04-gmt gdb_5_3-2002-09-04-branchpoint insight+dejagnu
+$ @kbd{^echo ^^}
+@dots{}
+$ @kbd{echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \}
+> @kbd{-b -r gdb_$V-$D-branchpoint gdb_$V-branch insight+dejagnu}
cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
--b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight+dejagnu
-$ ^echo ^^
-...
-$
+-b -r gdb_5_3-2002-03-03-branchpoint gdb_5_3-branch insight+dejagnu
+$ @kbd{^echo ^^}
+@dots{}
@end smallexample
@itemize @bullet
@@ -5641,28 +5702,39 @@
@file{version.in} gets bumped to avoid version number conflicts
@item
the reading of @file{.cvsrc} is disabled using @file{-f}
+@item
+@samp{rtag} is used so that the need to initally check out the
+repository is avoided (@samp{rtag} is much faster.
@end itemize
-@subheading Update @file{version.in}
+@subheading Update @file{version.in} and @file{ChangeLog}
+
+As well as updating the file @file{version.in} on the branch, an entry
+is added to both the branch and mainline @file{ChangeLog} files.
@smallexample
-$ u=5.1
-$ v=5.2
-$ V=`echo $v | sed 's/\./_/g'`
-$ echo $u $v$V
-5.1 5_2
-$ cd /tmp
-$ echo cvs -f -d :ext:sources.redhat.com:/cvs/src co \
--r gdb_$V-branch src/gdb/version.in
+$ @kbd{u=5.2}
+$ @kbd{v=5.3}
+$ @kbd{V=`echo $v | sed 's/\./_/g'`}
+$ @kbd{echo $u $v $V}
+5.2 5.3 5_3
+$ @kbd{cd /tmp}
+$ @kbd{echo cvs -f -d :ext:sources.redhat.com:/cvs/src co \}
+@kbd{-r gdb_$V-branch src/gdb/version.in}
cvs -f -d :ext:sources.redhat.com:/cvs/src co
- -r gdb_5_2-branch src/gdb/version.in
-$ ^echo ^^
+ -r gdb_5_3-branch src/gdb/version.in src/gdb/ChangeLog
+$ @kbd{^echo ^^}
U src/gdb/version.in
-$ cd src/gdb
-$ echo $u.90-0000-00-00-cvs > version.in
-$ cat version.in
-5.1.90-0000-00-00-cvs
-$ cvs -f commit version.in
+$ @kbd{cd src/gdb}
+$ @kbd{echo $u.90_0000-00-00-cvs > version.in}
+$ @kbd{cat version.in}
+5.2.90_0000-00-00-cvs
+$ @kbd{emacs version.in}
+@kbd{C-X 4 a}
+@dots{}
+$ @kbd{emacs ChangeLog @dots{}@var{trunk}/ChangeLog}
+@dots{} insert entry @dots{}
+$ @kbd{cvs -f commit version.in ChangeLog}
@end smallexample
@itemize @bullet
@@ -5672,13 +5744,12 @@
@item
@file{.90} and the previous branch version are used as fairly arbitrary
initial branch version number
+@item
+The mainline @file{ChangeLog} entry will likely need to be inserted
+between two existing entries since other commits may have gone through.
+Don't forget to post a patch.
@end itemize
-
-@subheading Update the web and news pages
-
-Something?
-
@subheading Tweak cron to track the new branch
The file @file{gdbadmin/cron/crontab} contains gdbadmin's cron table.
@@ -5700,7 +5771,7 @@
snapshot directories.
-@subheading Update the NEWS and README files
+@subheading Update the @file{NEWS}, @file{README}, @file{PROBLEMS} and @file{doc/gdbint.texinfo} files
The @file{NEWS} file needs to be updated so that on the branch it refers
to @emph{changes in the current release} while on the trunk it also
@@ -5709,16 +5780,27 @@
The @file{README} file needs to be updated so that it refers to the
current release.
+The @file{PROBLEMS} file needs to be updated so that it refers to this
+current release.
+
+The @file{doc/gdb.texinfo} needs to be updated to mention the release
+engineer.
+
+@subheading Update the web and news pages
+
+Don't forget to update both @file{htdocs/index.html} and
+@file{htdocs/news/index.html}.
+
@subheading Post the branch info
-Send an announcement to the mailing lists:
+Send separate announcements to the mailing lists:
@itemize @bullet
@item
@email{gdb-announce@@sources.redhat.com, GDB Announcement mailing list}
@item
@email{gdb@@sources.redhat.com, GDB Discsussion mailing list} and
-@email{gdb-testers@@sources.redhat.com, GDB Discsussion mailing list}
+@email{gdb-testers@@sources.redhat.com, GDB Testers mailing list}
@end itemize
@emph{Pragmatics: The branch creation is sent to the announce list to
@@ -5766,18 +5848,17 @@
@subsubheading Establish a few defaults.
@smallexample
-$ b=gdb_5_2-branch
-$ v=5.2
-$ t=/sourceware/snapshot-tmp/gdbadmin-tmp
-$ echo $t/$b/$v
-/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
-$ mkdir -p $t/$b/$v
-$ cd $t/$b/$v
-$ pwd
-/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
-$ which autoconf
+$ @kbd{b=gdb_5_3-branch}
+$ @kbd{v=5.3}
+$ @kbd{t=/sourceware/snapshot-tmp/gdbadmin-tmp}
+$ @kbd{echo $t/$b/$v}
+/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_3-branch/5.3
+$ @kbd{mkdir -p $t/$b/$v}
+$ @kbd{cd $t/$b/$v}
+$ @kbd{pwd}
+/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_3-branch/5.3
+$ @kbd{which autoconf}
/home/gdbadmin/bin/autoconf
-$
@end smallexample
@noindent
@@ -5795,11 +5876,10 @@
@subsubheading Check out the relevant modules:
@smallexample
-$ for m in gdb insight dejagnu
-do
-( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
-done
-$
+$ @kbd{for m in gdb insight dejagnu; do}
+> @kbd{mkdir -p $m}
+> @kbd{( cd $m && cvs -q -f -d /cvs/src co -P -r $b $m ) > Co.$m}
+> @kbd{done}
@end smallexample
@noindent
@@ -5807,8 +5887,8 @@
@itemize @bullet
@item
-The reading of @file{.cvsrc} is disabled (@file{-f}) so that there isn't
-any confusion between what is written here and what your local
+The reading of @file{~/.cvsrc} is disabled (@file{-f}) so that there
+isn't any confusion between what is written here and what your local
@code{cvs} really does.
@end itemize
@@ -5821,41 +5901,73 @@
Major releases get their comments added as part of the mainline. Minor
releases should probably mention any significant bugs that were fixed.
-Don't forget to include the @file{ChangeLog} entry.
+@smallexample
+$ @kbd{emacs gdb/src/gdb/NEWS}
+@dots{}
+@kbd{c-x 4 a}
+@dots{}
+@kbd{c-x c-s c-x c-c}
+$ @kbd{cp gdb/src/gdb/NEWS insight/src/gdb/NEWS}
+$ @kbd{cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog}
+@end smallexample
+
+@noindent
+Be sure to:
+
+@itemize @bullet
+update the text ``Changes since @dots{}'' to ``Changes in @dots{}''.
+@item
+add an entry to the @file{ChangeLog} file
+@end itemize
+
+@item gdb/PROBLEMS
+
+If you know of any specific problems in the release related to building
+it, add them here. Hopefully the branch process has already updated the
+version number in this file.
@smallexample
-$ emacs gdb/src/gdb/NEWS
-...
-c-x 4 a
-...
-c-x c-s c-x c-c
-$ cp gdb/src/gdb/NEWS insight/src/gdb/NEWS
-$ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
+$ @kbd{emacs gdb/src/gdb/PROBLEMS}
+@dots{}
+@kbd{c-x 4 a}
+@dots{}
+@kbd{c-x c-s c-x c-c}
+$ @kbd{cp gdb/src/gdb/PROBLEMS insight/src/gdb/PROBLEMS}
+$ @kbd{cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog}
@end smallexample
+@noindent
+Often problems are only identifed after the final release candidate has
+been made. That is fine. Just add them to the @file{PROBLEMS} on the
+trunk. That way the web pages ``known problems'' link, at least, is
+up-to-date.
+
@item gdb/README
-You'll need to update:
+@smallexample
+$ @kbd{emacs gdb/src/gdb/README}
+@dots{}
+@kbd{c-x 4 a}
+@dots{}
+@kbd{c-x c-s c-x c-c}
+$ @kbd{cp gdb/src/gdb/README insight/src/gdb/README}
+$ @kbd{cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog}
+@end smallexample
+
+@noindent
+Be sure to:
@itemize @bullet
@item
-the version
+update the version number throughout the file
+@item
+change the ``Updated @dots{}'' date
@item
-the update date
+change the ``Updated @dots{}'' person
@item
-who did it
+add an entry to the @file{ChangeLog} file
@end itemize
-@smallexample
-$ emacs gdb/src/gdb/README
-...
-c-x 4 a
-...
-c-x c-s c-x c-c
-$ cp gdb/src/gdb/README insight/src/gdb/README
-$ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
-@end smallexample
-
@emph{Maintainer note: Hopefully the @file{README} file was reviewed
before the initial branch was cut so just a simple substitute is needed
to get it updated.}
@@ -5867,60 +5979,69 @@
@item gdb/version.in
@smallexample
-$ echo $v > gdb/src/gdb/version.in
-$ cat gdb/src/gdb/version.in
-5.2
-$ emacs gdb/src/gdb/version.in
-...
-c-x 4 a
-... Bump to version ...
-c-x c-s c-x c-c
-$ cp gdb/src/gdb/version.in insight/src/gdb/version.in
-$ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
+$ @kbd{echo $v > gdb/src/gdb/version.in}
+$ @kbd{cat gdb/src/gdb/version.in}
+5.3
+$ @kbd{emacs gdb/src/gdb/version.in}
+@dots{}
+@kbd{c-x 4 a}
+@dots{} Bump to version @dots{}
+@kbd{c-x c-s c-x c-c}
+$ @kbd{cp gdb/src/gdb/version.in insight/src/gdb/version.in}
+$ @kbd{cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog}
@end smallexample
@item dejagnu/src/dejagnu/configure.in
Dejagnu is more complicated. The version number is a parameter to
-@code{AM_INIT_AUTOMAKE}. Tweak it to read something like gdb-5.1.91.
-
-Don't forget to re-generate @file{configure}.
-
-Don't forget to include a @file{ChangeLog} entry.
+@code{AM_INIT_AUTOMAKE}. Tweak it to read something like gdb-5.2.1.
@smallexample
-$ emacs dejagnu/src/dejagnu/configure.in
-...
-c-x 4 a
-...
-c-x c-s c-x c-c
-$ ( cd dejagnu/src/dejagnu && autoconf )
+$ @kbd{emacs dejagnu/src/dejagnu/configure.in}
+@dots{}
+@kbd{c-x 4 a}
+@dots{} (AM_INIT_AUTOMAKE): Bump to version @dots{}
+@kbd{c-x c-s c-x c-c}
+$ @kbd{( cd dejagnu/src/dejagnu && autoconf )}
@end smallexample
+@noindent
+Be sure to:
+
+@itemize @bullet
+@item
+update AM_INIT_AUTOMAKE
+@item
+re-generate @file{configure}.
+@item
+add an entry to the file @file{ChangeLog}
+@end itemize
+
@end table
@subsubheading Do the dirty work
This is identical to the process used to create the daily snapshot.
+@emph{This is being changed to src-release.}
+
@smallexample
-$ for m in gdb insight
-do
-( cd $m/src && gmake -f Makefile.in $m.tar )
-done
-$ ( m=dejagnu; cd $m/src && gmake -f Makefile.in $m.tar.bz2 )
+$ @kbd{for m in gdb insight; do}
+> @kbd{( cd $m/src && gmake -f Makefile.in $m.tar )}
+> @kbd{done}
+$ @kbd{( m=dejagnu; cd $m/src && gmake -f Makefile.in $m.tar.bz2 )}
@end smallexample
@subsubheading Check the source files
You're looking for files that have mysteriously disappeared.
@kbd{distclean} has the habit of deleting files it shouldn't. Watch out
-for the @file{version.in} update @kbd{cronjob}.
+for the @file{gdb/version.in} being updated by @kbd{cronjob}.
@smallexample
-$ ( cd gdb/src && cvs -f -q -n update )
+$ @kbd{( cd gdb/src && cvs -f -q -n update )}
M djunpack.bat
-? gdb-5.1.91.tar
+? gdb-5.2.91.tar
? proto-toplev
@dots{} lots of generated files @dots{}
M gdb/ChangeLog
@@ -5928,7 +6049,6 @@
M gdb/README
M gdb/version.in
@dots{} lots of generated files @dots{}
-$
@end smallexample
@noindent
@@ -5940,16 +6060,28 @@
@subsubheading Create compressed versions of the release
@smallexample
-$ cp */src/*.tar .
-$ cp */src/*.bz2 .
-$ ls -F
-dejagnu/ dejagnu-gdb-5.2.tar.bz2 gdb/ gdb-5.2.tar insight/ insight-5.2.tar
-$ for m in gdb insight
-do
-bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
-gzip -v -9 -c $m-$v.tar > $m-$v.tar.gz
-done
-$
+$ @kbd{cp */src/*.tar .}
+$ @kbd{cp */src/*.bz2 .}
+$ @kbd{ls -1F}
+@dots{}
+dejagnu/
+dejagnu-gdb-5.3.tar.bz2
+gdb/
+gdb-5.3.tar
+insight/
+insight-5.3.tar
+$ @kbd{for m in gdb insight; do}
+> @kbd{bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2}
+> @kbd{gzip -v -9 -c $m-$v.tar > $m-$v.tar.gz}
+> @kbd{done}
+@dots{}
+$ @kbd{chmod a=r *.gz *.bz2}
+$ @kbd{ls -1 *.bz2 *.gz}
+dejagnu-gdb-5.3.tar.bz2
+gdb-5.3.tar.bz2
+gdb-5.3.tar.gz
+insight-5.3.tar.bz2
+insight-5.3.tar.gz
@end smallexample
@noindent
@@ -5961,50 +6093,83 @@
in that mode, @code{gzip} does not know the name of the file and, hence,
can not include it in the compressed file. This is also why the release
process runs @code{tar} and @code{bzip2} as separate passes.
+@item
+The @option{-c} option and redirection are used so that neither neither
+@code{bzip2} nor @code{gzip} remove the input tar archives.
@end itemize
@subsection Sanity check the tar ball
-Pick a popular machine (Solaris/PPC?) and try the build on that.
+Pick a popular machine and try the build on that.
@smallexample
-$ bunzip2 < gdb-5.2.tar.bz2 | tar xpf -
-$ cd gdb-5.2
-$ ./configure
-$ make
+$ @kbd{bunzip2 < gdb-5.3.tar.bz2 | tar xpf -}
+$ @kbd{cd gdb-5.3 && ./configure && make}
@dots{}
-$ ./gdb/gdb ./gdb/gdb
-GNU gdb 5.2
+$ @kbd{./gdb/gdb ./gdb/gdb}
+GNU gdb 5.2.91
@dots{}
-(gdb) b main
+(gdb) @kbd{b main}
Breakpoint 1 at 0x80732bc: file main.c, line 734.
-(gdb) run
-Starting program: /tmp/gdb-5.2/gdb/gdb
+(gdb) @kbd{run}
+Starting program: /tmp/gdb-5.3/gdb/gdb
Breakpoint 1, main (argc=1, argv=0xbffff8b4) at main.c:734
734 catch_errors (captured_main, &args, "", RETURN_MASK_ALL);
-(gdb) print args
-$1 = @{argc = 136426532, argv = 0x821b7f0@}
+(gdb) @kbd{info args}
+argc = 1
+argv = (char **) 0xbffff8a4
(gdb)
@end smallexample
-@subsection Make a release candidate available
+@subsection Make the release candidate available
-If this is a release candidate then the only remaining steps are:
+If this is a @emph{draft} release candidate then the only remaining
+steps are:
@enumerate
@item
-Commit @file{version.in} and @file{ChangeLog}
+Commit @file{version.in}, @file{ChangeLog} and any other motified files.
@item
-Tweak @file{version.in} (and @file{ChangeLog} to read
-@var{L}.@var{M}.@var{N}-0000-00-00-cvs so that the version update
-process can restart.
+Add the suffis @samp{_0000-00-00-cvs} to @file{version.in} so that it
+reads something like @samp{5.2.91_0000-00-00-cvs}. The
+@file{version.in} update process will then resume (also tweak/commit
+@file{ChangeLog}).
@item
-Make the release candidate available in
+Make the release candidate available on@*
@uref{ftp://sources.redhat.com/pub/gdb/snapshots/branch}
+(@file{~ftp/pub/gdb/snapshots/branch}).
+@item
+Notify the relevant mailing lists:
+@itemize @bullet
+@item
+@email{gdb@@sources.redhat.com}
+@item
+@email{gdb-testers@@sources.redhat.com}
+@end itemize
+that the draft release candidate is available include the ftp path).
+@end enumerate
+
+@noindent
+If this the @emph{final} release candiate then the @value{GDBN}
+developers are still going to need early access:
+
+@enumerate
+@item
+Create a copy of the official relase candidate, calling it something
+like @file{gdb-5.2.91.tar.bz2}. Put that up for ftp on@*
+@uref{ftp://sources.redhat.com/pub/gdb/snapshots/branch}
+(@file{~ftp/pub/gdb/snapshots/branch})
+@item
+Notify the relevant mailing lists
+@itemize @bullet
+@item
+@email{gdb@@sources.redhat.com}
@item
-Notify the relevant mailing lists ( @email{gdb@@sources.redhat.com} and
-@email{gdb-testers@@sources.redhat.com} that the candidate is available.
+@email{gdb-testers@@sources.redhat.com}
+@end itemize
+that the candidate is available include the ftp path). Indicate when it
+will become official (give a few days).
@end enumerate
@subsection Make a formal release available
@@ -6016,17 +6181,21 @@
Copy the new files to both the release and the old release directory:
@smallexample
-$ cp *.bz2 *.gz ~ftp/pub/gdb/old-releases/
-$ cp *.bz2 *.gz ~ftp/pub/gdb/releases
+$ @kbd{cd $t/$b/$v}
+$ @kbd{cp *.bz2 *.gz ~ftp/pub/gdb/old-releases/}
+$ @kbd{cp *.bz2 *.gz ~ftp/pub/gdb/releases}
@end smallexample
@noindent
+Be careful to not also copy any pre-release versions (e.g.,
+gdb-5.2.0.92.tar.bz2).
+
Clean up the releases directory so that only the most recent releases
-are available (e.g. keep 5.2 and 5.2.1 but remove 5.1):
+are available (e.g., keep 5.3 and 5.2.1 but remove 5.2):
@smallexample
-$ cd ~ftp/pub/gdb/releases
-$ rm @dots{}
+$ @kbd{cd ~ftp/pub/gdb/releases}
+$ @kbd{rm @dots{}}
@end smallexample
@noindent
@@ -6034,26 +6203,37 @@
directory:
@smallexample
-$ vi README
+$ @kbd{vi README}
@dots{}
-$ rm -f .message
-$ ln README .message
+$ @kbd{rm -f .message}
+$ @kbd{ln README .message}
@end smallexample
+@subsubheading Install the @value{GDBN} tar ball on GNU
+
+At the time of writing, the GNU machine was @kbd{gnudist.gnu.org} in
+@file{~ftp/gnu/gdb}. This is done early so that it is possible to
+update the @file{ANNOUNCEMENT} file with correct information.
+
@subsubheading Update the web pages.
@table @file
@item htdocs/download/ANNOUNCEMENT
-This file, which is posted as the official announcement, includes:
+This file, which is posted as the official announcement, includes many
+things that need to be updated:
@itemize @bullet
@item
-General announcement
+General announcement.
+@item
+File details (md5 checksum and @code{ls -l} output).
@item
News. If making an @var{M}.@var{N}.1 release, retain the news from
earlier @var{M}.@var{N} release.
@item
-Errata
+Reference to previous release (version and date).
+@item
+Problems (errata).
@end itemize
@item htdocs/index.html
@@ -6075,36 +6255,36 @@
Something like:
@smallexample
-$ ~/ss/update-web-docs \
- ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
- $PWD/www \
- /www/sourceware/htdocs/gdb/download/onlinedocs \
- gdb
+$ @kbd{pwd}
+/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_3-branch/5.3
+$ @kbd{/bin/sh ~/ss/update-web-docs \}
+> @kbd{$PWD/gdb-5.3.tar.bz2 \}
+> @kbd{$PWD/www \}
+> @kbd{/www/sourceware/htdocs/gdb/download/onlinedocs \}
+> @kbd{gdb}
@end smallexample
@item download/ari/
Just like the online documentation. Something like:
@smallexample
-$ /bin/sh ~/ss/update-web-ari \
- ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
- $PWD/www \
- /www/sourceware/htdocs/gdb/download/ari \
- gdb
+$ @kbd{pwd}
+/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_3-branch/5.3
+$ @kbd{/bin/sh ~/ss/update-web-ari \}
+> @kbd{$PWD/gdb-5.3.tar.bz2 \}
+> @kbd{$PWD/www \}
+> @kbd{/www/sourceware/htdocs/gdb/download/ari \}
+> @kbd{gdb}
@end smallexample
@end table
+
@subsubheading Shadow the pages onto gnu
Something goes here.
-@subsubheading Install the @value{GDBN} tar ball on GNU
-
-At the time of writing, the GNU machine was @kbd{gnudist.gnu.org} in
-@file{~ftp/gnu/gdb}.
-
@subsubheading Make the @file{ANNOUNCEMENT}
Post the @file{ANNOUNCEMENT} file you created above to:
@@ -6136,20 +6316,28 @@
@file{gdb/NEWS}
@item
@file{gdb/README}
+@item
+@file{gdb/PROBLEMS}
@end itemize
+@noindent
+Watch out for @file{version.in}, it will likely have been upated by
+cron.
+
@subsubheading Tag the release
Something like:
@smallexample
-$ d=`date -u +%Y-%m-%d`
-$ echo $d
-2002-01-24
-$ ( cd insight/src/gdb && cvs -f -q update )
-$ ( cd insight/src && cvs -f -q tag gdb_5_2-$d-release )
+$ @kbd{d=`date -u +%Y-%m-%d`}
+$ @kbd{echo $d}
+2002-12-12
+$ @kbd{( cd insight/src/gdb && cvs -f -q update )}
+@dots{} you may need to clean up some files @dots{}
+$ @kbd{( cd insight/src && cvs -f -q tag gdb_5_3-$d-release )}
@end smallexample
+@noindent
Insight is used since that contains more of the release than
@value{GDBN} (@code{dejagnu} doesn't get tagged but I think we can live
with that).
@@ -6164,8 +6352,8 @@
If @file{gdb/version.in} does not contain an ISO date such as
@kbd{2002-01-24} then the daily @code{cronjob} won't update it. Having
committed all the release changes it can be set to
-@file{5.2.0_0000-00-00-cvs} which will restart things (yes the @kbd{_}
-is important - it affects the snapshot process).
+@file{5.3.0.90_0000-00-00-cvs} which will restart things (yes the
+@kbd{_} is important - it affects the snapshot process).
Don't forget the @file{ChangeLog}.
@@ -6181,7 +6369,7 @@
generated by running:
@smallexample
-$ ~/ss/schedule `date +%s` schedule
+$ @kbd{~/ss/schedule `date +%s` schedule}
@end smallexample
@noindent
@@ -6192,7 +6380,8 @@
@section Post release
-Remove any @code{OBSOLETE} code.
+Remove any @code{OBSOLETE} code. (This only applies to the first
+release after a new branch.)
@node Testsuite
--------------070403000308090609080302--