aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMark Linimon <linimon@FreeBSD.org>2004-01-20 23:56:34 +0000
committerMark Linimon <linimon@FreeBSD.org>2004-01-20 23:56:34 +0000
commit7f9ca5dcf90a5a0184f59c05d56afbaf180e0e5c (patch)
tree4c376d03c5d58fef13286e84a16cd5c4acf2a7f0
parentebcb93faac52d3ce82c6a0b1fe7d6a1a55394bea (diff)
downloaddoc-7f9ca5dcf90a5a0184f59c05d56afbaf180e0e5c.tar.gz
doc-7f9ca5dcf90a5a0184f59c05d56afbaf180e0e5c.zip
[ports committer:] in a few cases, the Handbook introduces a concept,
elaborates on the concept, and then justifies the reason for the concept. This make the document read a little bit strangely. This fix switches the latter two. Very little new text is introduced, just some rewording. PR: docs/61653 (partial) Reviewed by: ceri Approved by: ceri
Notes
Notes: svn path=/head/; revision=19764
-rw-r--r--en_US.ISO8859-1/books/porters-handbook/book.sgml65
1 files changed, 32 insertions, 33 deletions
diff --git a/en_US.ISO8859-1/books/porters-handbook/book.sgml b/en_US.ISO8859-1/books/porters-handbook/book.sgml
index 550a60678d..806f94eea2 100644
--- a/en_US.ISO8859-1/books/porters-handbook/book.sgml
+++ b/en_US.ISO8859-1/books/porters-handbook/book.sgml
@@ -348,8 +348,19 @@ lib/X11/oneko/mouse.xpm
Also add a short description of the program you ported
to the <quote>Description</quote> field of the PR and
the shar or uuencoded tarfile to the
- <quote>Fix</quote> field. The latter one helps the committers
- a lot, who use scripts for the ports-work.</para>
+ <quote>Fix</quote> field.</para>
+
+ <note>
+ <para>You can make our work a lot easier, if you use a good
+ description in the synopsis of the problem report.
+ We prefer something like
+ <quote>New port: &lt;category&gt;/&lt;portname&gt;
+ &lt;short description of the port&gt;</quote> for new ports and
+ <quote>Update port: &lt;category&gt;/&lt;portname&gt;
+ &lt;short description of the update&gt;</quote> for port updates.
+ If you stick to this scheme, the chance that someone will take a
+ look at your PR soon is much better.</para>
+ </note>
<para>One more time, <emphasis>do not include the original source
distfile, the <filename>work</filename> directory, or the package
@@ -375,18 +386,6 @@ lib/X11/oneko/mouse.xpm
<ulink url="../../articles/contributors/contrib-additional.html">Additional FreeBSD Contributors</ulink>
and other files. Isn't that great?!? <!-- smiley
-->:-)</para>
-
- <note>
- <para>You can make our work a lot easier, if you use a good
- description in the synopsis of the problem report.
- We prefer something like
- <quote>New port: &lt;short description of the port&gt;</quote> for
- new ports and
- <quote>Update port: &lt;category&gt;/&lt;port&gt; &lt;short description
- of the update&gt;</quote> for port updates.
- If you stick to this scheme, the chance that one takes a look at
- your PR soon is much bigger.</para>
- </note>
</sect1>
</chapter>
@@ -757,8 +756,13 @@ lib/X11/oneko/mouse.xpm
every increase of <makevar>PORTVERSION</makevar> (i.e.
every time a new official vendor release is made), and
appended to the package name if non-zero.
- <makevar>PORTREVISION</makevar> is increased each time a
- change is made to the FreeBSD port which significantly
+ Changes to <makevar>PORTREVISION</makevar> are
+ used by automated tools (e.g. &man.pkg.version.1;)
+ to highlight the fact that a new package is
+ available.</para>
+
+ <para><makevar>PORTREVISION</makevar> should be increased
+ each time a change is made to the port which significantly
affects the content or structure of the derived
package.</para>
@@ -846,10 +850,7 @@ lib/X11/oneko/mouse.xpm
actually work at all), and weigh that against that fact
that it will cause everyone who regularly updates their
ports tree to be compelled to update. If yes, the
- <makevar>PORTREVISION</makevar> should be bumped so that
- automated tools (e.g. &man.pkg.version.1;)
- will highlight the fact that a new package is
- available.</para>
+ <makevar>PORTREVISION</makevar> should be bumped.</para>
</sect3>
<sect3>
@@ -1814,8 +1815,7 @@ PORTEPOCH= 1</programlisting>
If your port <emphasis>is</emphasis> an X
application, define <makevar>USE_XLIB</makevar> (implied by
<makevar>USE_IMAKE</makevar>) and put it in the appropriate
- categories. Also, many of them go into other
- <filename>x11-*</filename> categories (see below).</entry>
+ category.</entry>
</row>
<row>
@@ -2793,7 +2793,9 @@ PATCHFILES= patch1:test</programlisting>
<para>Set your mail-address here. Please. <!-- smiley
--><emphasis>:-)</emphasis></para>
- <para>The format used should be <literal>user@hostname.domain</literal>.
+ <para>Note that only a single address without the comment part is
+ allowed as a <makevar>MAINTAINER</makevar> value.
+ The format used should be <literal>user@hostname.domain</literal>.
Please do not include any descriptive text such as your real
name in this entry&mdash;that merely confuses
<filename>bsd.port.mk</filename>. Instead, put that information
@@ -2803,9 +2805,6 @@ PATCHFILES= patch1:test</programlisting>
refer to the <ulink url="../developers-handbook/policies.html#POLICIES-MAINTAINER">MAINTAINER on
Makefiles</ulink> section.</para>
- <para>Note that only a single address without comment part is
- allowed as a <makevar>MAINTAINER</makevar> value.</para>
-
<para>If the maintainer of a port does not respond to an update
request from a user after two weeks (excluding major public
holidays), then that is considered a maintainer timeout, and the
@@ -4634,23 +4633,23 @@ PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}</programlisting>
<para>If the maintainer asks you to do the upgrade or the maintainer
is <literal>ports@FreeBSD.org</literal>,
- please make the upgrade and send the
+ please make the upgrade and save the result of the
recursive <command>diff</command> output
of the new and old
- ports directories to us (e.g., if your modified port directory is
+ ports directories (e.g., if your modified port directory is
called <filename>superedit</filename> and the original is in our tree
- as <filename>superedit.bak</filename>, then send us the result of
+ as <filename>superedit.bak</filename>, then save the result of
<command>diff -ruN superedit.bak superedit</command>). Either
unified or context diff is fine, but port committers generally
prefer unified diffs. Note the use of the <literal>-N</literal>
option&mdash;this is the accepted way to force diff to properly
deal with the case of new files being added or old files being
- deleted.</para>
+ deleted. Before sending us the diff, please examine the
+ output to make sure all the changes make sense.</para>
- <para>Please examine
- the output to make sure all the changes make sense. The best way to
+ <para> The best way to
send us the diff is by including it via &man.send-pr.1; (category
- <literal>ports</literal>). If you are the maintainer for the port,
+ <literal>ports</literal>). If you are going to be the maintainer for the port,
be sure to put <literal>[maintainer update]</literal> at the beginning
of your synopsis line and/or set the <quote>Class</quote> of your PR
to <literal>maintainer-update</literal>. Please mention any added or