FreeBSD documentation project prefers to use manual pages over man pages,
hence some documents should reflect this. Tossed around on: -doc -developers
This commit is contained in:
parent
0708fdd160
commit
d4b003e30a
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=13596
25 changed files with 72 additions and 72 deletions
|
|
@ -579,11 +579,11 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>You will almost certainly get a conflict because
|
||||
of the <literal>$Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $</literal> (or in FreeBSD's case,
|
||||
of the <literal>$Id: article.sgml,v 1.130 2002-07-11 19:07:44 trhodes 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.129 2002-07-03 23:19:04 jim Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $</literal> line intact).</para>
|
||||
the second <literal>$Id: article.sgml,v 1.130 2002-07-11 19:07:44 trhodes Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.130 2002-07-11 19:07:44 trhodes Exp $</literal> line intact).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -1197,7 +1197,7 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
|
||||
<listitem>
|
||||
<para>Ruslan is Mister &man.mdoc.7;. If you are writing a
|
||||
man page and need
|
||||
manual page and need
|
||||
some advice on the structure, or the markup, ask Ruslan.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -1595,7 +1595,7 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
committed only once something resembling consensus has
|
||||
been reached. This does not mean that you have to ask
|
||||
permission before correcting every obvious syntax error or
|
||||
man page misspelling, simply that you should try to
|
||||
manual page misspelling, simply that you should try to
|
||||
develop a feel for when a proposed change is not quite such
|
||||
a no-brainer and requires some feedback first. People
|
||||
really do not mind sweeping changes if the result is
|
||||
|
|
@ -1711,7 +1711,7 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
developers, so allow some time to elapse before merging
|
||||
unless the &os.stable; fix is critical,
|
||||
time sensitive or so obvious as to make further testing
|
||||
unnecessary (spelling fixes to man pages, obvious bug/typo
|
||||
unnecessary (spelling fixes to manual pages, obvious bug/typo
|
||||
fixes, etc.) In other words, apply common sense.</para>
|
||||
|
||||
<para>Changes to the security branches
|
||||
|
|
@ -1843,7 +1843,7 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
<command>make lint</command>.</para>
|
||||
|
||||
<para>For all on-line manual pages, run <command>manck</command>
|
||||
(from ports) over the man page to verify all of the cross
|
||||
(from ports) over the manual page to verify all of the cross
|
||||
references and file references are correct and that the man
|
||||
page has all of the appropriate <makevar>MLINK</makevar>s
|
||||
installed.</para>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue