[rfa/doc] ``The Release Cycle''

[Andrew Cagney <ac131313 at cygnus dot com>]

Another tweak, I've had lying around for a while.

Provides a brief overview of the release cycle and how it occures.

ok?
Andrew
2002-06-01  Andrew Cagney  <ac131313@redhat.com>

	* gdbint.texinfo (Releasing GDB): New section ``The Release
	Cycle''.

Index: gdbint.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.86
diff -u -r1.86 gdbint.texinfo
--- gdbint.texinfo	31 May 2002 01:36:16 -0000	1.86
+++ gdbint.texinfo	1 Jun 2002 20:02:06 -0000
@@ -5028,6 +5028,45 @@
 @chapter Releasing @value{GDBN}
 @cindex making a new release of gdb
 
+
+@section The Release Cycle
+
+At the time of writing, the plan was to have three releases a year.
+This puts @value{GDBN} on a seventeen week release cycle (@kbd{52 / 3 =
+17}).  The theory also goes that a release branch is held open for five
+weeks before the release is made.
+
+The exact schedule is maintained using @code{cron} and the shell script
+@code{ss/schedule}.  Things are set up to send out e-mail notifying the
+@kbd{gdbadmin} of key times in the schedule, in particular:
+
+@itemize @bullet
+@item
+two weeks to branch (week 0)
+@item
+one week to branch (week 1)
+@item
+branch (week 2)
+@item
+two weeks to release (week 5)
+@item
+one week to release (week 6)
+@item
+release (week 6)
+@end itemize
+
+@emph{Pratmatics: GCC is on a six month release cycle.  It is hoped that
+@value{GDBN} with its more incremental process can handle being released
+more often --- the process involving less overhead.}
+
+@emph{Pratmatics: Using @code{cron} is an act of desperation.  At least
+@code{cron} doesn't back out at the last moment.}
+
+@emph{To do: Should the @code{schedule} script's e-mail be sent either
+@email{gdb-announce@@sources.redhat.com} or
+@email{gdb@@sources.redhat.com}.}
+
+
 @section Versions and Branches
 
 @subsection Version Identifiers