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 Description field of the PR and the shar or uuencoded tarfile to the - Fix field. The latter one helps the committers - a lot, who use scripts for the ports-work. + Fix field. + + + 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 + New port: <category>/<portname> + <short description of the port> for new ports and + Update port: <category>/<portname> + <short description of the update> for port updates. + If you stick to this scheme, the chance that someone will take a + look at your PR soon is much better. + One more time, do not include the original source distfile, the work directory, or the package @@ -375,18 +386,6 @@ lib/X11/oneko/mouse.xpm Additional FreeBSD Contributors and other files. Isn't that great?!? :-) - - - 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 - New port: <short description of the port> for - new ports and - Update port: <category>/<port> <short description - of the update> for port updates. - If you stick to this scheme, the chance that one takes a look at - your PR soon is much bigger. - @@ -757,8 +756,13 @@ lib/X11/oneko/mouse.xpm every increase of PORTVERSION (i.e. every time a new official vendor release is made), and appended to the package name if non-zero. - PORTREVISION is increased each time a - change is made to the FreeBSD port which significantly + Changes to PORTREVISION are + used by automated tools (e.g. &man.pkg.version.1;) + to highlight the fact that a new package is + available. + + PORTREVISION should be increased + each time a change is made to the port which significantly affects the content or structure of the derived package. @@ -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 - PORTREVISION should be bumped so that - automated tools (e.g. &man.pkg.version.1;) - will highlight the fact that a new package is - available. + PORTREVISION should be bumped. @@ -1814,8 +1815,7 @@ PORTEPOCH= 1 If your port is an X application, define USE_XLIB (implied by USE_IMAKE) and put it in the appropriate - categories. Also, many of them go into other - x11-* categories (see below). + category. @@ -2793,7 +2793,9 @@ PATCHFILES= patch1:test Set your mail-address here. Please. :-) - The format used should be user@hostname.domain. + Note that only a single address without the comment part is + allowed as a MAINTAINER value. + The format used should be user@hostname.domain. Please do not include any descriptive text such as your real name in this entry—that merely confuses bsd.port.mk. Instead, put that information @@ -2803,9 +2805,6 @@ PATCHFILES= patch1:test refer to the MAINTAINER on Makefiles section. - Note that only a single address without comment part is - allowed as a MAINTAINER value. - 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} If the maintainer asks you to do the upgrade or the maintainer is ports@FreeBSD.org, - please make the upgrade and send the + please make the upgrade and save the result of the recursive diff 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 superedit and the original is in our tree - as superedit.bak, then send us the result of + as superedit.bak, then save the result of diff -ruN superedit.bak superedit). Either unified or context diff is fine, but port committers generally prefer unified diffs. Note the use of the -N option—this is the accepted way to force diff to properly deal with the case of new files being added or old files being - deleted. + deleted. Before sending us the diff, please examine the + output to make sure all the changes make sense. - Please examine - the output to make sure all the changes make sense. The best way to + The best way to send us the diff is by including it via &man.send-pr.1; (category - ports). If you are the maintainer for the port, + ports). If you are going to be the maintainer for the port, be sure to put [maintainer update] at the beginning of your synopsis line and/or set the Class of your PR to maintainer-update. Please mention any added or