Check-In Requirements

[Mark Mitchell <mark at codesourcery dot com>]

It appears that there may still be a little confusion as to our
check-in requirements.  Following an excellent suggestion from the SC,
I have attempted to codify them.  These are my words only.  I believe
I have faithfully represented our community standards, but I in no way
object not at all to people making edits as appropriate.

Thanks in advance for reading this, and for your comments.

This diff was applied to the cvswrite.html web page for reference.
Here is the change:

Index: cvswrite.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/cvswrite.html,v
retrieving revision 1.24
retrieving revision 1.26
diff -c -p -r1.24 -r1.26
*** cvswrite.html	2000/05/11 07:00:34	1.24
--- cvswrite.html	2000/06/01 18:00:44	1.26
*************** href="http://gcc.gnu.org/ml/gcc-cvs/">gc
*** 127,132 ****
--- 127,169 ----
  <hr>
  <a name="checkin"><h2>Checking in a change</h2></a>
  
+ <p>It is expected that before you check in any change you will do the
+ following:
+ <ul>
+ <li>If your change is to code that is not in a front-end, or is to the
+     C front-end, verify that the compiler bootstraps with your change.
+     You must bootstrap all languages, not just C.  You must bootstrap
+     with exactly the change that you intended to check in; it's not
+     good enough to have bootstrapped with an earlier variant.  (Unless
+     the only changes from the earlier variant are formatting and
+     comment changes; if there are <emph>any</emph> changes to the code
+     itself you should re-bootstrap.)
+ 
+ <li>If your change is to code that is not in a front-end, or is to   
+     the C front-end, verify that the all of the GCC regression tests
+     behave identically before and after your patch.   You can do a
+     <code>make check</code> at the top of the tree to run all of the
+     tests.
+ 
+ <li>If your change is to code that is in a front-end, other than the C
+     front-end, you need to verify only that the tests for that
+     language have not regressed.  You need not bootstrap, or test
+     other languages, since there is no way you could have affected
+     them.  If there is a run-time library written in the language
+     compiled by your front-end, you should, however, verify that it
+     continues to build.
+ 
+ <li>When you post your change to <code>gcc-patches</code>, indicate
+     what platform you have used for testing.
+ </ul>
+ These rules are designed to ensure that checked-in code does not
+ contain bugs that prevent other people from continuing to get their
+ work done.  There will always be bugs, but these rules help to
+ minimize the amount of time where the tree does not build at
+ all. Repeated failure to adhere to these rules could result in the
+ revocation of check-in privileges by the Steering Committee.
+ </p>
+ 
  <p>This is meant to provide a very quick overview of how to check in a
  change.  It is not meant to be a replacement for the CVS manual but 
  instead a supplement.  The CVS manual is distributed as part of the CVS

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com