diff options
| -rw-r--r-- | en_US.ISO8859-1/articles/committers-guide/article.sgml | 58 |
1 files changed, 29 insertions, 29 deletions
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 @@ </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> |