diff --git a/en_US.ISO8859-1/articles/committers-guide/article.sgml b/en_US.ISO8859-1/articles/committers-guide/article.sgml
index ac3c3f42d6..cd18704e63 100644
--- a/en_US.ISO8859-1/articles/committers-guide/article.sgml
+++ b/en_US.ISO8859-1/articles/committers-guide/article.sgml
@@ -22,7 +22,7 @@
- $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.78 2001/07/14 03:38:03 obrien Exp $
+ $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.79 2001/07/15 05:22:50 dd Exp $
1999
@@ -502,13 +502,13 @@
copy.
For instance, say you commit a change to
- shazam/shazam.c in -CURRENT and later
+ shazam/shazam.c in &os.current; and later
want to MFC it. The change you want to MFC was revision
1.15:
- Check out the -STABLE version of the
+ Check out the &os.stable; version of the
shazam module:
&prompt.user; cvs co -rRELENG_4 shazam
@@ -522,11 +522,11 @@
You'll almost certainly get a conflict because
- of the $Id: article.sgml,v 1.79 2001-07-15 05:22:50 dd Exp $ (or in FreeBSD's case,
+ of the $Id: article.sgml,v 1.80 2001-07-15 06:33:28 dd Exp $ (or in FreeBSD's case,
$FreeBSD$) lines, so you'll have to edit
the file to resolve the conflict (remove the marker lines and
- the second $Id: article.sgml,v 1.79 2001-07-15 05:22:50 dd Exp $ line, leaving the original
- $Id: article.sgml,v 1.79 2001-07-15 05:22:50 dd Exp $ line intact).
+ the second $Id: article.sgml,v 1.80 2001-07-15 06:33:28 dd Exp $ line, leaving the original
+ $Id: article.sgml,v 1.80 2001-07-15 06:33:28 dd Exp $ line intact).
@@ -879,10 +879,10 @@ checkout -P
first few commits by your mentor before committing it to the
repository.
- All commits should go to -CURRENT first
- before being merged to -STABLE. No major new
+ 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
- -STABLE branch.
+ &os.stable; branch.
@@ -1136,8 +1136,8 @@ docs:Documentation Bug:nik:
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 -CURRENT to
- -STABLE (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.
@@ -1329,15 +1329,15 @@ docs:Documentation Bug:nik:
- Changes go to -CURRENT before
- -STABLE unless specifically permitted by
+ Changes go to &os.current; before
+ &os.stable; unless specifically permitted by
the release engineer or unless they're not applicable to
- -CURRENT. 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
- -CURRENT 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
- -STABLE branch as outlined for the
+ &os.stable; branch as outlined for the
maintainer in rule #6.
@@ -1570,15 +1570,15 @@ docs:Documentation Bug:nik:
- Changes go to -CURRENT before
- -STABLE unless specifically permitted
+ Changes go to &os.current; before
+ &os.stable; unless specifically permitted
by the release engineer or unless they're not applicable
- to -CURRENT. Any non-trivial or
+ to &os.current;. Any non-trivial or
non-urgent change which is applicable should also be
- allowed to sit in -CURRENT 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 -STABLE branch as outlined in rule
+ the &os.stable; branch as outlined in rule
#6.
This is another don't argue about it
@@ -1586,18 +1586,18 @@ docs:Documentation Bug:nik:
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
- -STABLE branch. The management of
- -STABLE 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 -STABLE and different rules
- apply there than in -CURRENT. There's
- also really no point in having -CURRENT
+ 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
- -STABLE immediately. Changes need a
- chance to be tested by the -CURRENT
+ &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 -STABLE 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.