Use &os.current; and &os.stable; where appropriate.

Submitted by:	Mike Barcroft <mike@q9media.com>

en_US.ISO8859-1/articles/committers-guide/article.sgml

@@ -22,7 +22,7 @@
       </author>
     </authorgroup>
 
-    <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.78 2001/07/14 03:38:03 obrien Exp $</pubdate>
+    <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.79 2001/07/15 05:22:50 dd Exp $</pubdate>
 
     <copyright>
       <year>1999</year>
@@ -502,13 +502,13 @@
           copy.</para>
 
         <para>For instance, say you commit a change to
-          <filename>shazam/shazam.c</filename> in -CURRENT and later
+          <filename>shazam/shazam.c</filename> in &os.current; and later
           want to MFC it.  The change you want to MFC was revision
           1.15:</para>
 
         <itemizedlist>
           <listitem>
-            <para>Check out the -STABLE version of the
+            <para>Check out the &os.stable; version of the
               <filename>shazam</filename> module:</para>
 
             <screen>&prompt.user; <userinput>cvs co -rRELENG_4 shazam</userinput></screen>
@@ -522,11 +522,11 @@
         </itemizedlist>
 
         <para>You'll almost certainly get a conflict because
-          of the <literal>$Id: article.sgml,v 1.79 2001-07-15 05:22:50 dd Exp $</literal> (or in FreeBSD's case,
+          of the <literal>$Id: article.sgml,v 1.80 2001-07-15 06:33:28 dd Exp $</literal> (or in FreeBSD's case,
           <literal>$FreeBSD<!-- stop expansion -->$</literal>) lines, so you'll have to edit
           the file to resolve the conflict (remove the marker lines and
-          the second <literal>$Id: article.sgml,v 1.79 2001-07-15 05:22:50 dd Exp $</literal> line, leaving the original
-          <literal>$Id: article.sgml,v 1.79 2001-07-15 05:22:50 dd Exp $</literal> line intact).</para>
+          the second <literal>$Id: article.sgml,v 1.80 2001-07-15 06:33:28 dd Exp $</literal> line, leaving the original
+          <literal>$Id: article.sgml,v 1.80 2001-07-15 06:33:28 dd Exp $</literal> line intact).</para>
       </listitem>
 
       <listitem>
@@ -879,10 +879,10 @@ checkout -P</programlisting>
       first few commits by your mentor before committing it to the
       repository.</para>
 
-    <para>All commits should go to <literal>-CURRENT</literal> first
-      before being merged to <literal>-STABLE</literal>.  No major new
+    <para>All commits should go to &os.current; first
+      before being merged to &os.stable;.  No major new
       features or high-risk modifications should be made to the
-      <literal>-STABLE</literal> branch.</para>
+      &os.stable; branch.</para>
   </sect1>
 
   <sect1 id="developer.relations">
@@ -1136,8 +1136,8 @@ docs:Documentation Bug:nik:</programlisting>
 	    process.  During code freezes, he also has final authority
 	    on all changes to the system for whichever branch is
 	    pending release status.  If there is something you want
-	    merged from <literal>-CURRENT</literal> to
-	    <literal>-STABLE</literal> (whatever values those may have
+	    merged from &os.current; to
+	    &os.stable; (whatever values those may have
 	    at any given time), he is also the one to talk to about
 	    it.</para>
 	</listitem>
@@ -1329,15 +1329,15 @@ docs:Documentation Bug:nik:</programlisting>
       </listitem>
 
       <listitem>
-	<para>Changes go to <literal>-CURRENT</literal> before
-	  <literal>-STABLE</literal> unless specifically permitted by
+	<para>Changes go to &os.current; before
+	  &os.stable; unless specifically permitted by
 	  the release engineer or unless they're not applicable to
-	  <literal>-CURRENT</literal>.  Any non-trivial or non-urgent
+	  &os.current;.  Any non-trivial or non-urgent
 	  change which is applicable should also be allowed to sit in
-	  <literal>-CURRENT</literal> for at least 3 days before
+	  &os.current; for at least 3 days before
 	  merging so that it can be given sufficient testing.  The
 	  release engineer has the same authority over the
-	  <literal>-STABLE</literal> branch as outlined for the
+	  &os.stable; branch as outlined for the
 	  maintainer in rule #6.</para>
       </listitem>
 
@@ -1570,15 +1570,15 @@ docs:Documentation Bug:nik:</programlisting>
 	</listitem>
 
 	<listitem>
-	  <para>Changes go to <literal>-CURRENT</literal> before
-	    <literal>-STABLE</literal> unless specifically permitted
+	  <para>Changes go to &os.current; before
+	    &os.stable; unless specifically permitted
 	    by the release engineer or unless they're not applicable
-	    to <literal>-CURRENT</literal>.  Any non-trivial or
+	    to &os.current;.  Any non-trivial or
 	    non-urgent change which is applicable should also be
-	    allowed to sit in <literal>-CURRENT</literal> for at least
+	    allowed to sit in &os.current; for at least
 	    3 days before merging so that it can be given sufficient
 	    testing.  The release engineer has the same authority over
-	    the <literal>-STABLE</literal> branch as outlined in rule
+	    the &os.stable; branch as outlined in rule
 	    #6.</para>
 	
 	  <para>This is another <quote>don't argue about it</quote>
@@ -1586,18 +1586,18 @@ docs:Documentation Bug:nik:</programlisting>
 	    responsible (and gets beaten up) if a change turns out to
 	    be bad.  Please respect this and give the release engineer
 	    your full cooperation when it comes to the
-	    <literal>-STABLE</literal> branch.  The management of
-	    <literal>-STABLE</literal> may frequently seem to be
+	    &os.stable; branch.  The management of
+	    &os.stable; may frequently seem to be
 	    overly conservative to the casual observer, but also bear
 	    in mind the fact that conservatism is supposed to be the
-	    hallmark of <literal>-STABLE</literal> and different rules
-	    apply there than in <literal>-CURRENT</literal>.  There's
-	    also really no point in having <literal>-CURRENT</literal>
+	    hallmark of &os.stable; and different rules
+	    apply there than in &os.current;.  There's
+	    also really no point in having &os.current;
 	    be a testing ground if changes are merged over to
-	    <literal>-STABLE</literal> immediately.  Changes need a
-	    chance to be tested by the <literal>-CURRENT</literal>
+	    &os.stable; immediately.  Changes need a
+	    chance to be tested by the &os.current;
 	    developers, so allow some time to elapse before merging
-	    unless the <literal>-STABLE</literal> fix is critical,
+	    unless the &os.stable; fix is critical,
 	    time sensitive or so obvious as to make further testing
 	    unnecessary (spelling fixes to manpages, obvious bug/typo
 	    fixes, etc.)  In other words, apply common sense.</para>