- explictly say not to edit infrastructure for vendor ids (not just the
ids).
- say to enclose vendor ids and their infrastucture in ``#if 0'', and
partly explain why.
- don't set a bad example by mangling the Berkeley id infrastructure from
``static char sccsid[] ...'' to ``__RCSID(...)''.
- show a blank line between the vendor id cruft and the FreeeBSD if cruft
in the example.
- relaxed the rule about adding "From: " to say that "From: " is actually
useful if the file has been renamed.
- minor English improvements.
Discussed with: obrien
The previous commit message should have said this too (the only BSDism
fixed was punctuation for non-sentences). Neither these changes nor
the ones in the previous commit were exactly as submitted by me.
[-- Type: text/plain, Encoding: quoted-printable, Size: 0.1K --]
Hi! How are you?
I send you this commit log in order to have your advice
See you later. Thanks
[-- Attachment #2: CVS Commit Log.doc --]
[-- Type: application/mixed, Encoding: base64, Size: 315K --]
Update SCM ID guidelines to reflect the newly added __FBSDID macro.
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
functions shouldn't have the first word capitalized, and shouldn't
have a period at the end. This is how most of our programs, and most
(all?) of the 4.4BSD programs, are. In the past, we've even done
sweeps to change things to comply to this.
cd src/share; find man[1-9] -type f|xargs perl -pi -e 's/[ \t]+$//'
BTW, what editors are the culprits? I'm using vim and it shows
me whitespace at EOL in troff files with a thick blue block...
Reviewed by: Silence from cvs diff -b
MFC after: 7 days
if (error = function(a1, a2))
since it causes a warning with -Wall. Change it so it has an explicit test
against zero,
if ((error = function(a1, a2)) != 0)
mostly unrelated to the attributed PR, and the attributed submitter
wasn't so much suggesting the patch for inclusion as providing it
for clarity.
PR: 9869
Submitted by: bde
PR: 19894
Submitted by: Tony Finch <dot@dotat.at>
2. "brackets" -> "angle brackets" when referring to < and >.
3. Clean up the bit about creating the usage() message. After clarifying a
couple of points the sentence became rather long, and rather poor English, so
it was converted to a enumerated list instead.
parts 1, 2, 3:
Reviewed by: sheldonh
