Hello,

This updates the gdbint.texinfo doco to reflect what did (and should) 
happen during the GDB 5.2 release cycle.

I've also included the raw text.  The patch is somewhat unreadable.

enjoy,
Andrew


@section Create a Release

The process of creating and then making available a release is broken
down into a number of stages.  The first part addresses the technical
process of creating a releasable tar ball.  The later stages address the
process of releasing that tar ball.

When making a release candidate just the first section is needed.

@subsection Create a release candidate

The objective at this stage is to create a set of tar balls that can be
made available as a formal release (or as a less formal release
candidate).

@subsubheading Freeze the branch

Send out an e-mail notifying everyone that the branch is frozen to
@email{gdb-patches@@sources.redhat.com}.

@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
/home/gdbadmin/bin/autoconf
$
@end smallexample

@noindent
Notes:

@itemize @bullet
@item
Check the @code{autoconf} version carefully.  You want to be using the
version taken from the @file{binutils} snapshot directory.  It is very
unlikely that a system installed version of @code{autoconf} (e.g.,
@file{/usr/bin/autoconf}) is correct.
@end itemize

@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
$
@end smallexample

@noindent
Note:

@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
@code{cvs} really does.
@end itemize

@subsubheading Update relevant files.

@table @file

@item gdb/NEWS

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
$  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
@end smallexample

@item gdb/README

You'll need to update:

@itemize @bullet
@item
the version
@item
the update date
@item
who did it
@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.}

@emph{Maintainer note: Other projects generate @file{README} and
@file{INSTALL} from the core documentation.  This might be worth
pursuing.}

@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
@end smallexample

@item dejagnu/src/dejagnu/configure.in

Dejagnu is more complicated.  The version number is a parameter to
@var{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.

@smallexample
$  emacs dejagnu/src/dejagnu/configure.in
...
c-x 4 a
...
c-x c-s c-x c-c
$  ( cd  dejagnu/src/dejagnu && autoconf )
@end smallexample

@end table

@subsubheading Do the dirty work

This is identical to the process used to create the daily snapshot.

@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 )
@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}.

@smallexample
$  ( cd gdb/src && cvs -f -q -n update )
M djunpack.bat
? gdb-5.1.91.tar
? proto-toplev
@dots{} lots of generated files @dots{}
M gdb/ChangeLog
M gdb/NEWS
M gdb/README
M gdb/version.in
@dots{} lots of generated files @dots{}
$
@end smallexample

@noindent
@emph{Don't worry about the @file{gdb.info-??} or
@file{gdb/p-exp.tab.c}.  They were generated (and yes @file{gdb.info-1}
was also generated only something strange with CVS means that they
didn't get supressed).  Fixing it would be nice though.}

@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
$
@end smallexample

@noindent
Note:

@itemize @bullet
@item
A pipe such as @kbd{bunzip2 < xxx.bz2 | gzip -9 > xxx.gz} is not since,
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.
@end itemize

@subsection Sanity check the tar ball

Pick a popular machine (Solaris/PPC?) and try the build on that.

@smallexample
$  bunzip2 < gdb-5.2.tar.bz2 | tar xpf -
$  cd gdb-5.2
$  ./configure
$  make
@dots{}
$  ./gdb/gdb ./gdb/gdb
GNU gdb 5.2
@dots{}
(gdb)  b main
Breakpoint 1 at 0x80732bc: file main.c, line 734.
(gdb)  run
Starting program: /tmp/gdb-5.2/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)
@end smallexample

@subsection Make a release candidate available

If this is a release candidate then the only remaining steps are:

@enumerate
@item
Commit @file{version.in} and @file{ChangeLog}
@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.
@item
Make the release candidate available in
@uref{ftp://sources.redhat.com/pub/gdb/snapshots/branch}
@item
Notify the relevant mailing lists ( @email{gdb@@sources.redhat.com} and
@email{gdb-testers@@sources.redhat.com} that the candidate is available.
@end enumerate

@subsection Make a formal release available

(And you thought all that was required was to post an e-mail.)

@subsubheading Install on sware

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
@end smallexample

@noindent
Clean up the releases directory so that only the most recent releases
are available (eg 5.2 and 5.2.1 but remote 5.1):

@smallexample
$  cd ~ftp/pub/gdb/releases
$  rm @dots{}
@end smallexample

@noindent
Update the file @file{README} and @file{.message} in the releases
directory:

@smallexample
$  vi README
@dots{}
$  rm -f .message
$  ln README .message
@end smallexample

@subsubheading Update the web pages.

@table @file

@item htdocs/download/ANNOUNCEMENT
This file, which is posted as the official announcement, includes:
@itemize @bullet
@item
General announcement
@item
News.  If making an @var{M}.@var{N}.1 release, retain the news from
earlier @var{M}.@var{N} release.
@item
Errata
@end itemize

@item htdocs/index.html
@itemx htdocs/news/index.html
@itemx htdocs/download/index.html
These files include:
@itemize @bullet
@item
announcement of the most recent release
@item
news entry (remember to update both the top level and the news directory).
@end itemize
These pages also need to be regenerate using @code{index.sh}.

@item download/onlinedocs/
You need to find the magic command that is used to generate the online
docs from the @file{.tar.bz2}.  The best way is to look in the output
from one of the nightly @code{cron} jobs and then just edit accordingly.
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
@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
@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:

@itemize @bullet
@item
@email{gdb-announce@@sources.redhat.com, GDB Announcement mailing list}
@item
@email{info-gnu@@gnu.org, General GNU Announcement list} (but delay it a
day or so to let things get out)
@item
@email{bug-gdb@@gnu.org, GDB Bug Report mailing list}
@end itemize

@subsection Cleanup

The release is out but you're still not finished.

@subsubheading Commit outstanding changes

In particular you'll need to commit any changes to:

@itemize @bullet
@item
@file{gdb/ChangeLog}
@item
@file{gdb/version.in}
@item
@file{gdb/NEWS}
@item
@file{gdb/README}
@end itemize

@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 )
@end smallexample

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

@subsubheading Mention the release on the trunk

Just put something in the @file{ChangeLog} so that the trunk also
indicates when the release was made.

@subsubheading Restart @file{gdb/version.in}

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

Don't forget the @file{ChangeLog}.

@subsubheading Merge into trunk

The files committed to the branch may also need changes merged into the
trunk.

@subsubheading Revise the release schedule

Post a revised release schedule to @email{gdb@@sources.redhat.com, GDB
Discussion List} with an updated announcement.  The schedule can be
generated by running:

@smallexample
$  ~/ss/schedule `date +%s` schedule
@end smallexample

@noindent
The first parameter is approximate date/time in seconds (from the epoc)
of the most recent release).

Also update the schedule @code{cronjob}.