o Mention that doceng are responsible for doc commit bits.

o doc committers are also the group primarily responsible for www/
o Update an outdated example GNATS categories file
o Point a link to the Staff list at the Staff list
o Remove the text associated with the "Don't Touch The Repo" Rule
o Update references within the Big List of Rules
This commit is contained in:
Ceri Davies 2003-03-01 22:24:58 +00:00
parent fad95edc7e
commit f30a5cf6c8
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=16160

View file

@ -145,8 +145,8 @@
<row>
<entry>doc</entry>
<entry>nik@</entry>
<entry>doc/, src/ documentation</entry>
<entry>doceng@</entry>
<entry>doc/, www/, src/ documentation</entry>
</row>
<row>
@ -608,11 +608,11 @@
</itemizedlist>
<para>You will almost certainly get a conflict because
of the <literal>$Id: article.sgml,v 1.158 2003-03-01 22:19:04 ceri Exp $</literal> (or in FreeBSD's case,
of the <literal>$Id: article.sgml,v 1.159 2003-03-01 22:24:58 ceri Exp $</literal> (or in FreeBSD's case,
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>)
lines, so you will have to edit the file to resolve the conflict
(remove the marker lines and the second <literal>$Id: article.sgml,v 1.158 2003-03-01 22:19:04 ceri Exp $</literal> line,
leaving the original <literal>$Id: article.sgml,v 1.158 2003-03-01 22:19:04 ceri Exp $</literal> line intact).</para>
(remove the marker lines and the second <literal>$Id: article.sgml,v 1.159 2003-03-01 22:24:58 ceri Exp $</literal> line,
leaving the original <literal>$Id: article.sgml,v 1.159 2003-03-01 22:24:58 ceri Exp $</literal> line intact).</para>
</listitem>
<listitem>
@ -875,7 +875,7 @@ checkout -P</programlisting>
(<filename role="package">editors/vim5</filename>) have color support and when used as
a pager with color syntax highlighting switched on will
highlight many types of file, including diffs, patches,
and cvs/rcs logs. </para>
and CVS/RCS logs. </para>
<screen>&prompt.user; <userinput>echo "syn on" &gt;&gt; ~/.vimrc </userinput>
&prompt.user; <userinput>cvs diff -Nu shazam | vim -</userinput>
@ -1089,10 +1089,6 @@ checkout -P</programlisting>
<para><ulink url="../../../../support.html">http://www.FreeBSD.org/support.html</ulink></para>
</listitem>
<listitem>
<para><ulink url="../../../../send-pr.html">http://www.FreeBSD.org/send-pr.html</ulink></para>
</listitem>
<listitem>
<para>&man.send-pr.1;</para>
</listitem>
@ -1163,7 +1159,7 @@ pending:Category for faulty PRs:gnats-admin:
#
# FreeBSD categories
#
docs:Documentation Bug:nik:</programlisting>
docs:Documentation Bug:freebsd-doc:</programlisting>
</step>
<step>
@ -1208,6 +1204,8 @@ docs:Documentation Bug:nik:</programlisting>
probably get to know in your role as a committer. Briefly,
and by no means all-inclusively, these are:</para>
<!-- XXX The TRB are missing -->
<variablelist>
<varlistentry>
@ -1391,7 +1389,7 @@ docs:Documentation Bug:nik:</programlisting>
<term>&a.developers;</term>
<listitem>
<para>developers is all committers. This list was created to be a
<para>All committers are subscribed to -developers. This list was created to be a
forum for the committers <quote>community</quote> issues.
Examples are Core
voting, announcements, etc. This list is
@ -1521,7 +1519,7 @@ docs:Documentation Bug:nik:</programlisting>
merging so that it can be given sufficient testing. The
release engineer has the same authority over the
&os.stable; branch as outlined for the
maintainer in rule #6.</para>
maintainer in rule #5.</para>
</listitem>
<listitem>
@ -1710,31 +1708,11 @@ docs:Documentation Bug:nik:</programlisting>
someone who manages an overall category of FreeBSD
evolution, such as internationalization or networking.
See <ulink
url="../contributors/article.html">
url="../contributors/staff-who.html">
http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.html</ulink>
for more information on this.</para>
</listitem>
<listitem>
<para>Never touch the repository directly. Ask a
Repomeister.</para>
<para>This is pretty clear - you are not allowed to make
direct modifications to the CVS repository, period. In
case of difficulty, ask one of the repository meisters by
sending mail to the &a.cvs; and simply
wait for them to fix the problem and get back to you. Do
not attempt to fix the problem yourself!</para>
<para>If you are thinking about putting down a tag or doing a
new import of code on a vendor branch, you might also find
it useful to ask for advice first. A lot of people get
this wrong the first few times and the consequences are
expensive in terms of files touched and angry CVSup/CTM
folks who are suddenly getting a lot of changes sent over
unnecessarily.</para>
</listitem>
<listitem>
<para>Any disputed change must be backed out pending
resolution of the dispute if requested by a maintainer.
@ -1770,7 +1748,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 &os.stable; branch as outlined in rule
#6.</para>
#5.</para>
<para>This is another <quote>do not argue about it</quote>
issue since it is the release engineer who is ultimately
@ -1830,6 +1808,7 @@ docs:Documentation Bug:nik:</programlisting>
to resolve the dispute. All parties involved must then
agree to be bound by the decision reached by this 3rd
party.</para>
<!-- XXX Mention TRB here too -->
</listitem>
<listitem>
@ -1864,6 +1843,9 @@ docs:Documentation Bug:nik:</programlisting>
<listitem>
<para>Test your changes before committing them.</para>
<!-- XXX Needs update re sparc64 + pc98
Also, needs more details on which machines are available for testing
-->
<para>This may sound obvious, but if it really were so
obvious then we probably would not see so many cases of
people clearly not doing this. If your changes are to the