The OpenAFS man pages are discussed on the openafs-doc mailing list at
openafs.org. If you plan on contributing to the man page project,
- please join that mailing list and send suggestions, patches, and
+ please join that mailing list and send suggestions, patches*, and
contributions there. The coordinator of the OpenAFS man page project is
Russ Allbery <rra@stanford.edu>; feel free to contact me directly with
questions (although using the mailing list is generally better and will
probably result in a faster response).
+ * Although we still accept patch submissions to the list, it is
+ greatly preferred that you make your submission through Git to
+ the OpenAFS Gerrit instance (code review system). Information
+ can be found at <http://wiki.openafs.org/GitDevelopers/>
+
POD and Man Page Generation
The OpenAFS man pages are maintained in POD (Plain Old Documentation),
OpenAFS source tree (this will also regenerate the Autoconf scripts).
Conversion to HTML can be done via any of the POD to HTML converters
- available (there are many of them). Evaluation of the best tool to use
- for OpenAFS and exactly how to do the conversion to get the highest
- quality results is still underway; when complete, details will be
- included here.
+ available (there are many of them), but for best results (particularly
+ for crosslinks), use the generate-html script in this directory. You
+ will need to have the Pod::Simple Perl module installed. If your Perl
+ is not in /usr/bin, run generate-html explicitly with:
+
+ perl generate-html
+
+ It will generate HTML pages in the html subdirectory of this directory.
Formatting Standards
documents common options, and discusses the general use of the suite.
Then, each operation code in the suite should have a separate man page,
named after the command with the space between the command suite and the
- operation code replaced with an underscore.
+ operation code replaced with an underscore. The NAME section of the
+ operation man page must also use an underscore (fs_listacl, not fs
+ listacl) for compatibility with some man programs. The SYNOPSIS section
+ should, of course, use a space, since that's what the user must type.
All man pages must follow the standard layout for man page sections and
formatting. The best general reference is the pod2man man page,
* <I<>> for user-provided arguments (note the surrounding <>).
* I<> for terms being defined or titles of works.
* C<> for command examples, ACL characters, and example arguments.
+ * S<<<>>> for text with non-breaking spaces (usually in synopsis).
Also see the afs(1) man page for general rules about how OpenAFS man
pages are formatted and for standard terminology to use when talking
own copyright and a statement that the man page is released under the
IBM Public License Version 1.0, or under some other license that is
sufficiently compatible that we can use your work. If you use another
- license and that license isn't "public domain," you have to give the
- full license text in the man page; please don't use a license so long
- that this is annoying.
+ license and that license isn't "public domain" or one of the ones
+ already listed in our LICENSE file, you have to give the full license
+ text in the man page; please don't use a license so long that this is
+ annoying.
The SYNOPSIS section should start with the full command name and the
full names of all options, and then have a second section showing the
References to functions should be noted like function() with the
trailing parens. The POD converters know how to format these sorts of
references appropriately. References to other sections in the same page
- should be given as L<SECTION>.
+ should be given as L<SECTION>. Man pages for all other AFS commands or
+ file formats referenced in the page should be listed in the SYNOPSIS.
+ List each reference on its own line for easier addition of other
+ references later, but don't put blank lines between them. Don't forget
+ the commas at the end of each line but the last.
Command and output examples should be indented three spaces. Commands
entered by the user should be given on a line beginning with %. If the
surrounding the variable. For consistency in formatting, references to
those variables should be formatted the same in following text.
+Man Page Sections
+
+ The section of a man page is determined by which directory it's in.
+ pod1 will be section 1 man pages, pod3 will be section 3, pod5 will be
+ section 5, and pod8 will be section 8.
+
+ The breakdown between section 1 and section 8 is fuzzy and it's hard to
+ get right. The current layout balances the following goals:
+
+ * In general, section 1 is used for commands that can be executed by any
+ user and section 8 is used for commands that can only be meaningfully
+ issued as root. If a command can be run with AFS privileged
+ credentials but still as a regular user on the local system, the
+ preference is for it to be in section 1, although some pages of that
+ type are in section 8.
+
+ * All the commands for a given suite should be kept together. So, for
+ example, there are fs commands that can only be issued as root, but
+ since most of the suite is available to any user, all of the fs
+ commands are in section 1.
+
+ * The sections of the man pages should roughly correspond to the
+ installation paths of the binaries. Binaries installed in bin should
+ have man pages in section 1 and binaries installed in sbin should have
+ man pages in section 8.
+
+ Section 5 should be used for all documentation of configuration files
+ and file formats.
+
How You Can Help
- The OpenAFS man page project is just starting, and a lot of work remains
- to be done. Any and all contributions are greatly appreciated. What
- follows is a list of the ways that you can help in order of increasing
- helpfulness. If you only have time to do something near the top of the
- list, please do; every little bit helps. If you have more time and can
- do something closer to the bottom of the list, that's even better and
- your contribution can be included more rapidly.
+ A lot of work remains to be done on the OpenAFS man page project. Any
+ and all contributions are greatly appreciated. What follows is a list
+ of the ways that you can help in order of increasing helpfulness. If
+ you only have time to do something near the top of the list, please do;
+ every little bit helps. If you have more time and can do something
+ closer to the bottom of the list, that's even better and your
+ contribution can be included more rapidly.
* Point out places OpenAFS behavior has changed since the documentation
was written, or point out missing documentation. Please check the
* Provide patches against the POD source that add or correct the
documentation of commands or file formats for changes in OpenAFS.
- Please send contributions either to the openafs-doc list or as bugs
- filed via the bug reporting instructions at <http://www.openafs.org/>.
- If you do submit a bug, please send me a note at rra@stanford.edu with
- the bug number so that I'm aware of it, as I don't always notice new
- bugs.
+ Please submit contributions to Gerrit or send them either to the
+ openafs-doc list or as bugs filed via the bug reporting instructions at
+ <http://www.openafs.org/>. If you do submit a bug, please send me a
+ note at rra@stanford.edu with the bug number so that I'm aware of it, as
+ I don't always notice new bugs.
+
+ You can test your new POD documentation by running the check-pod script
+ in this directory with "prove check-pod". (And check other people's
+ documentation and find any problems that have crept in.) You will need
+ to have Test::Pod installed.
Known Problems
don't just report the deficiency again, but any contributions towards
fixing it are greatly appreciated.
- * The section five and section eight man pages have not yet had an
- initial editing pass and many of the section five man pages are
- missing because the original reference page names didn't easily
- convert to man page names. This is currently being fixed. Please do
- not start working on the section five or section eight man pages yet
- or bother reporting problems with them; they will be changing
- significantly in the near future.
-
- * The following commands have no man pages:
-
- fs getcalleraccess
- fs getcrypt
- fs listaliases
- fs newalias
- fs rxstatpeer
- fs rxstatproc
- fs setcbaddr
- fs setcrypt
- pts interactive
- pts quit
- pts sleep
- pts source
- vos changeloc
- vos clone
- vos convertROtoRW
- vos copy
- vos shadow
- vos size
-
- * klog.krb, pagsh.krb, and tokens.krb need to be listed as alternative
- names in the NAME line of the non-.krb man pages, links should be
- installed on man page installation, and the behavior of pagsh.krb
- should be documented in the pagsh man page.
-
- * Some of the documentation in fs getserverprefs needs minor updates to
- reflect what happens in the dynroot case.
-
- * fs sysname documentation needs to include the possibility of setting
- multiple sysnames and the resulting behavior.
-
- * The afsd man page is horribly out of date. It doesn't explain
- dynroot, many options are missing, and some of the options described
- are no longer valid. It also still assumes that -settime is the
- default and says that the system must be rebooted after shutdown,
- which isn't the case at least on Linux.
-
- * All of the paths in the man pages are the Transarc paths. I'm not
- sure how best to deal with the possibility of installing OpenAFS in
- multiple different paths, but it would be good to at least
- acknowledge the issue.
-
- * bos listkeys assumes that you're using the kaserver.
-
- * I'm fairly sure that the fileserver man page no longer documents all
- of the fileserver options.
-
- * The package man page should probably mention the (pointless) package
- apropos and package help commands, or they could be removed. There
- used to be separate man pages for them, but that seemed rather
- pointless.
-
- * There are lingering references to AFS Development or AFS Product
- Support in descriptions of options that one should generally not
- use. Also, all of the manual references refer to the "IBM" manual.
- We should decide how to handle this terminology-wise.
+ * Linked cells are currently documented in fs newcell as being only
+ for DCE, which is not correct. That documentation, aklog, and the
+ CellServDB documentation needs to be updated.
+
+ * We need a way to add links to other man pages (kinit most notably)
+ without creating dangling links in the HTML output. This probably
+ means that the HTML conversion script needs to generate at startup
+ a list of all valid man page link targets and not linkify the ones
+ that don't match a valid target.
+
+ * Provide a way to substitute the correct paths into the HTML output
+ from Autoconf results.
+
+ * Review the sections used for all man pages against what directories
+ the commands are installed into. (In some cases, it may be better to
+ change the directory than the section of the man page.)
+
+ * Consider using M4 or similar to operate on POD text before output.
+ This would allow common options like vos -c,-noa,-l,-v,-e,-nor to be
+ documented once and automatically included in all vos_ reference
+ pages, much like the vos.c source includes those arguments as
+ COMMONPARMS.
+
+ * Check that suite intro pages mention all subcommands
+
+ Changes needed to have vos suite commands completely up to date,
+ including the 1.5 branch:
+
+ * Document vos create -minquota which is available since 1.5.61
+
+ * Document vos restore -creation/-lastupdate and -nodelete
+
+ Man section 8 suite commands:
+
+ * Mention bos (un)blockscanner in bos.pod text, not just in See Also
+ at the end
+
+ * Update backup source to include option descriptions (for content,
+ use existing manpage information "condensed" to half line of text)
+
+ * Document backup deletedump -port/-groupid/-dbonly/-force/-noexecute
+
+ * Document backup help -admin
+
+ * Document backup volrestore -usedump.
If you notice other problems, please send them to the openafs-doc list
even if you don't have time to fix them. Someone else might, and we
git://git.openafs.org / openafs.git / blobdiff