When PHK committed rev 1.50, he did not adjust the references to particular

rule numbers to take into account the new numbering.
This commit is contained in:
David E. O'Brien 2001-07-14 03:38:03 +00:00
parent 1c9cca9012
commit 0caaf5d84f
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=9897

View file

@ -19,7 +19,7 @@
</author>
</authorgroup>
<pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.76 2001/07/11 14:08:50 nik Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.77 2001/07/13 15:36:28 nik Exp $</pubdate>
<copyright>
<year>1999</year>
@ -519,11 +519,11 @@
</itemizedlist>
<para>You'll almost certainly get a conflict because
of the <literal>$Id: article.sgml,v 1.77 2001-07-13 15:36:28 nik Exp $</literal> (or in FreeBSD's case,
of the <literal>$Id: article.sgml,v 1.78 2001-07-14 03:38:03 obrien 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.77 2001-07-13 15:36:28 nik Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.77 2001-07-13 15:36:28 nik Exp $</literal> line intact).</para>
the second <literal>$Id: article.sgml,v 1.78 2001-07-14 03:38:03 obrien Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.78 2001-07-14 03:38:03 obrien Exp $</literal> line intact).</para>
</listitem>
<listitem>
@ -1335,7 +1335,7 @@ docs:Documentation Bug:nik:</programlisting>
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
maintainer in rule #5.</para>
maintainer in rule #6.</para>
</listitem>
<listitem>
@ -1576,7 +1576,7 @@ docs:Documentation Bug:nik:</programlisting>
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
#5.</para>
#6.</para>
<para>This is another <quote>don't argue about it</quote>
issue since it's the release engineer who is ultimately