This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [wip] How to release section
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 15 Jan 2002 09:56:40 +0200 (IST)
- Subject: Re: [wip] How to release section
On Tue, 15 Jan 2002, Andrew Cagney wrote:
> Attached is a (very obviously) work in progress patch for the internals
> manual going through how to release GDB.
Approved, with the following comments:
> + Mark as OBSOLETE any uninteresting targets or code files. This has a
> + number of steps and is slow - mainly to ensure that people have had a
^^^
Please use "---" when you want a dash. (The Texinfo manual explains
why--it's a TeX peculiarity.)
> + @item
> + announce the change on gdb@
You need to double every `@' in Texinfo. (Actually, I'd suggest to
use a full address here, like this:
announce the change on @email{gdb@@sources.redhat.com, GDB mailing list}
> + announce the change on gdb-announce@
Same here.
> + announce branch date
> + @item
> + wait a week
> + @item
> + you want to encourage people to sanity check their build as you really
> + don't want to be contending with configury problems as getting them
> + committed is complicated.
This last item looks like a footnote, and its style is different from
the other items. Perhaps it should be a @footnote.
> + As an aside, the branch tag name is probably regrettable vis:
> + gdb_N_M-YYYY-MM-DD-@{branch,branchpoint@}.
This should be in @file, and again double the `@'.
> + NB: Check the autoconf version carefully. You want to be using
> + gdbadmin's version (which is really the version taken from the binutils
`gdbadmin' is a command, so should be in @code.
> + NB: The reading of .cvsrc is disabled (-f) so that there isn't any
`.cvsrc' should be in @file.
> + @subheading Update the file gdb/version.in where applicable.
`gdb/version.in' should be in @file.
> + @subheading Mutter something about creating a ChangeLog entry. (both trunk and branch).
`ChangeLog' should be in @file.
> + @subheading Mutter something about updating README
`README' should be in @file.
> + For dejagnu, edit ``dejagnu/src/dejagnu/configure.in'' and set it to
`dejagnu/src/dejagnu/configure.in' should be in @file.
> + @subheading Do another CVS update to see what the damage is.
"CVS update" should be in @kbd (it's something you type at the
keyboard).
> + You're looking for files that have mysteriously disappeared as the
> + distclean has the habit of deleting files it shouldn't.
`distclean' should be in @samp or @kbd.
> + @subheading Copy all the .bz2 files to the ftp directory:
`.bz2' should be in @file.