os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

In general, tell people to send bug-fixes to gnats, not -hackers.

Browse source 
--
dannyman: Hey!  The handbook says to send submissions to &a.hackers;
jkh: Hmm...  It shouldn't.  Where's it say that?
dannyman: Oh, don't worry!  Tim Vanderhoek said he'd fix it!
hoek: What-huh!?  I never said that out loud, did I?

Zut!  ;-)
This commit is contained in:
Tim Vanderhoek 1998-02-11 09:28:33 +00:00
parent c1999db212
commit 400c75a14b
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=2419
1 changed files with 45 additions and 54 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

99
handbook/submitters.sgml
View file

@ -1,4 +1,4 @@
<!-- $Id: submitters.sgml,v 1.145 1998-02-04 12:21:28 tg Exp $ -->
<!-- $Id: submitters.sgml,v 1.146 1998-02-11 09:28:33 hoek Exp $ -->
<!-- The FreeBSD Documentation Project -->
<chapt><heading>Contributing to FreeBSD<label id="contrib"></heading>
@ -291,49 +291,43 @@ the next version)
<p>Contributions to the system generally fall into one or more of
the following 6 categories:
<sect1><heading>Bug reports and general commentary</heading>
<p>If you have a bug to report or a suggestion to make:
<sect1><heading>Bug reports and general commentary
<label id="contrib:general"></heading>
<itemize>
<item>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 <em>high</em>
volume of mail!) may
subscribe to the hackers mailing list by sending mail to
&a.majordomo;.
See <ref id="eresources:mail" name="mailing lists">
for more information about this and other mailing lists.
<p>An idea or suggestion of <em>general</em> technical interest
should be mailed to the &a.hackers;. Likewise, people with an
interest in such things (and a tolerance for a <em>high</em>
volume of mail!) may subscribe to the hackers mailing list by
sending mail to &a.majordomo;. See
<ref id="eresources:mail" name="mailing lists">
for more information about this and other mailing lists.
<item>An actual bug report should be filed by using the send-pr(1)
program or its <url url="http://www.freebsd.org/send-pr.html"
name="WEB based equivalent">. This will prompt you for various
fields to fill in. In the send-pr(1) case, simply go to the
fields surrounded by <tt>&lt;&gt;</tt>'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 <tt>send-pr(1)</tt> program or its
<url url="http://www.freebsd.org/send-pr.html" name="WEB-based equivalent">.
Try to fill-in each field in the bug report. Unless they exceed
65KB, include any patches directly in the report.
<p>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
<url url="mailto:bug-followup@freebsd.org"
name="bug-followup@freebsd.org"> 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
<url url="mailto:bug-followup@FreeBSD.ORG"
name="bug-followup@FreeBSD.ORG">. Use the number as the
message subject, e.g. <tt>"Re: kern/3377"</tt>. 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 <tt>send-pr(1)</tt> command,
then you may also file a bug report by sending mail to the &a.bugs;.
</itemize>
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 <tt>send-pr(1)</tt> command,
then you may ask someone to file it for you by sending mail
to the &a.bugs;.
<sect1><heading>Changes to the documentation</heading>
<p>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
<ref id="contrib:general" name="Bug Reports and General Commentary">.
<sect1><heading>Changes to existing source code</heading>
@ -368,31 +362,28 @@ diff -c -r olddir newdir
details.
Once you have a set of diffs (which you may test with the
<tt>patch(1)</tt> 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! :-)
<tt>patch(1)</tt> command), you should submit them for inclusion
with FreeBSD. Use the <tt>send-pr(1)</tt> program as described in
<ref id="contrib:general" name="Bug Reports and General Commentary">.
<em>Do not</em> 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 <tt>tar</tt>
file and running the <tt>uuencode(1)</tt> program on it before
sending the output of that to the &a.hackers;.
See the man pages on <tt>tar(1)</tt> and <tt>uuencode(1)</tt> 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 <tt>tar</tt> file
and run the <tt>uuencode(1)</tt> 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 <tt>send-pr(1)</tt>. 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
<em>very busy</em> 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 <tt>man 9 intro</tt> and <tt>man 9 style</tt>
for some information on coding style. We would appreciate
@ -401,7 +392,7 @@ diff -c -r olddir newdir
<sect1><heading>New code or major value-added packages</heading>
<p>In the case of a significant contribution of a large body
<p>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 <url