diff --git a/handbook/submitters.sgml b/handbook/submitters.sgml index 851577290e..4b6b9261a2 100644 --- a/handbook/submitters.sgml +++ b/handbook/submitters.sgml @@ -1,4 +1,4 @@ - + Contributing to FreeBSD @@ -291,49 +291,43 @@ the next version)

Contributions to the system generally fall into one or more of the following 6 categories: -Bug reports and general commentary -

If you have a bug to report or a suggestion to make: +Bug reports and general commentary + - - An idea or suggestion of general technical interest should be - mailed to the &a.hackers;. - Likewise, people with an interest - in such things (and a tolerance for a high - volume of mail!) may - subscribe to the hackers mailing list by sending mail to - &a.majordomo;. - See - for more information about this and other mailing lists. +

An idea or suggestion of general technical interest +should be mailed to the &a.hackers;. Likewise, people with an +interest in such things (and a tolerance for a high +volume of mail!) may subscribe to the hackers mailing list by +sending mail to &a.majordomo;. See + +for more information about this and other mailing lists. - An actual bug report should be filed by using the send-pr(1) - program or its . This will prompt you for various - fields to fill in. In the send-pr(1) case, simply go to the - fields surrounded by <>'s and fill in your own - information in place of what is suggested there. With the - WEB based interface, you simply select the appropriate items from - various option menus and fill in the various fields shown there. +If you find a bug or are submitting a specific change, please report +it using the send-pr(1) program or its +. +Try to fill-in each field in the bug report. Unless they exceed +65KB, include any patches directly in the report. -

You should receive confirmation of your bug report along with - a tracking number. Please keep this tracking number and refer to - it in any subsequent correspondence so that people can find the - details of your problem quickly. You may also send mail to - with your PR# in the subject - line to append further information to an existing bug report. +After filing a report, you should receive confirmation along with +a tracking number. Keep this tracking number so that you can +update us with details about the problem by sending mail to +. Use the number as the +message subject, e.g. "Re: kern/3377". Additional +information for any bug report should be submitted this way. - If you do not receive confirmation in a timely fashion (3 days to - a week, depending on your email connection) or are, for some - reason, unable to use the send-pr(1) command, - then you may also file a bug report by sending mail to the &a.bugs;. - +If you do not receive confirmation in a timely fashion (3 days to +a week, depending on your email connection) or are, for some +reason, unable to use the send-pr(1) command, +then you may ask someone to file it for you by sending mail +to the &a.bugs;. Changes to the documentation

Changes to the documentation are overseen by the &a.doc;. -This does not generally include -changes to manual pages, which should be considered under the category -of "changes to existing source code." +Send submissions and changes (even small ones are welcome!) +using send-pr as described in +. Changes to existing source code @@ -368,31 +362,28 @@ diff -c -r olddir newdir details. Once you have a set of diffs (which you may test with the - patch(1) command), you should bundle them up in an - email message and send it, along with a brief description of - what the diffs are for, to the &a.hackers;. - Someone will very - likely get back in touch with you in 24 hours or less, - assuming of course that your diffs are interesting! :-) + patch(1) command), you should submit them for inclusion + with FreeBSD. Use the send-pr(1) program as described in + . + Do not just send the diffs to the &a.hackers; or they will get + lost! We greatly appreciate your submission (this is a volunteer + project!); because we are busy, we may not be able to address it + immediately, but it will remain in the pr database until we do. - If your changes do not express themselves well as diffs alone - (e.g. you have perhaps added, deleted or renamed files as well) - then you may be better off bundling any new files, diffs and - instructions for deleting/renaming others into a tar - file and running the uuencode(1) program on it before - sending the output of that to the &a.hackers;. - See the man pages on tar(1) and uuencode(1) for more - information on bundling files this way. + If you feel it appropriate (e.g. you have added, deleted, or + renamed files), bundle your changes into a tar file + and run the uuencode(1) program on it. Shar archives are + also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, - then you should send it to &a.core; rather than the &a.hackers - The core mailing list + then you should send it to &a.core; directly rather than submitting + it with send-pr(1). The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them - in cases where mailing to hackers is truly impractical. + where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate @@ -401,7 +392,7 @@ diff -c -r olddir newdir New code or major value-added packages -

In the case of a significant contribution of a large body +

In the rare case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it becomes almost always necessary to either send changes as uuencode'd tar files or upload them to our ftp site