From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1835 invoked by alias); 27 Mar 2002 00:50:29 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1817 invoked from network); 27 Mar 2002 00:50:27 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 27 Mar 2002 00:50:27 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2FB583DFD for ; Tue, 26 Mar 2002 19:48:33 -0500 (EST) Message-ID: <3CA116E0.8070407@cygnus.com> Date: Tue, 26 Mar 2002 16:50:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [rfa/doc] Update Releasing GDB:Before the Branch Content-Type: multipart/mixed; boundary="------------060104070205040700070205" X-SW-Source: 2002-03/txt/msg00515.txt.bz2 This is a multi-part message in MIME format. --------------060104070205040700070205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1757 Hello, The attatched updates the doco to match what really happened before a branch is cut rather than what I vaguely remembered from cutting the last branch :-) ok? Andrew @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 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 Prompt for @file{gdb/NEWS} People always forget. Send a post reminding them but also if you know something interesting happened add it your self. The @code{schedule} script will mention this in its e-mail. @subheading Review @file{gdb/README} 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. 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 @subheading Check the ARI @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. @subsection Review the bug data base Close anything obviously fixed. @subsection Check all cross targets build The targets are listed in @file{gdb/MAINTAINERS}. --------------060104070205040700070205 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 4382 2002-03-25 Andrew Cagney * gdbint.texinfo (Releasing GDB): Revise the section `Before the Branch'. Index: gdbint.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v retrieving revision 1.70 diff -p -r1.70 gdbint.texinfo *** gdbint.texinfo 2002/03/19 02:49:53 1.70 --- gdbint.texinfo 2002/03/27 00:43:11 *************** no longer relevant or simply wrong. Sec *** 4989,5030 **** 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 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 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. ! 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. ! @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 ! As an aside, the branch tag name is probably regrettable vis: ! @smallexample ! gdb_N_M-YYYY-MM-DD-@{branch,branchpoint@} ! @end smallexample @subheading Refresh any imported files. --- 4989,5014 ---- 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 + 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 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 Prompt for @file{gdb/NEWS} ! People always forget. Send a post reminding them but also if you know ! something interesting happened add it your self. The @code{schedule} ! script will mention this in its e-mail. ! @subheading Review @file{gdb/README} ! 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. *************** A number of files are taken from externa *** 5034,5060 **** @item @file{texinfo/texinfo.tex} @item ! @file{config.guess} et.@: al.@: @end itemize ! and should be refreshed. ! @subheading Prompt for @file{gdb/NEWS} ! People always forget. Send a post reminding them but also if you know ! something interesting happened add it your self. ! @subheading Review @file{gdb/README} ! Grab one of the nightly snapshots and then walk through the ! @file{gdb/README} looking for anything that can be improved. ! @subheading Check the ARI - 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 --- 5018,5045 ---- @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 ! @subheading Check the ARI ! @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. ! @subsection Review the bug data base ! Close anything obviously fixed. ! @subsection Check all cross targets build ! The targets are listed in @file{gdb/MAINTAINERS}. @section Cut the branch --------------060104070205040700070205--