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

Whitespace changes needed after recent commits (and some additional

Browse source 
ones that were needed).  Translators may safely ignore.

Approved by:	ceri (mentor) (implicit)
This commit is contained in:
Mark Linimon 2004-05-24 04:12:43 +00:00
parent 8b1f3f8e28
commit 652d8b96e1
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=20987
1 changed files with 26 additions and 22 deletions

48
en_US.ISO8859-1/articles/problem-reports/article.sgml
View file

@ -77,10 +77,12 @@
engender a problem report. Of course, nobody is perfect, and
there will be times when you are convinced you have found a bug
in a program when in fact you have misunderstood the syntax for
a command or made a typographical error in a configuration file (though that in
a command or made a typographical error in a configuration file
(though that in
itself may sometimes be indicative of poor documentation or poor
error handling in the application). There are still many cases
where submitting a problem report is clearly <emphasis>not</emphasis> the right
where submitting a problem report is clearly
<emphasis>not</emphasis> the right
course of action, and will only serve to frustrate you and the
developers. Conversely, there are cases where it might be
appropriate to submit a problem report about something else than
@ -207,8 +209,10 @@
<filename>/usr/ports/UPDATING</filename> (for individual ports)
or <filename>/usr/ports/CHANGES</filename> (for changes
that affect the entire Ports Collection).
<ulink URL="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING"></ulink> and
<ulink URL="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES"></ulink> are also available via CVSweb.</para>
<ulink URL="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING"></ulink>
and
<ulink URL="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES"></ulink>
are also available via CVSweb.</para>
</listitem>
</itemizedlist>
@ -229,8 +233,7 @@
problem reports according to the category the originator
selected. Therefore, if you select the wrong category when you
submit your problem report, there is a good chance that it will
go unnoticed for a while, until someone re-categorizes
it.</para>
go unnoticed for a while, until someone re-categorizes it.</para>
</section>
<section id="pr-writing">
@ -250,7 +253,8 @@
<listitem>
<para><emphasis>Do not leave the <quote>Synopsis</quote>
line empty.</emphasis> The PRs go both onto a mailing list
that goes all over the world (where the <quote>Synopsis</quote> is used
that goes all over the world (where the <quote>Synopsis</quote>
is used
for the <literal>Subject:</literal> line), but also into a
database. Anyone who comes along later and browses the
database by synopsis, and finds a PR with a blank subject
@ -436,9 +440,9 @@
<title>Before you begin</title>
<para>Before running the &man.send-pr.1; program, make sure your
<envar>VISUAL</envar> (or <envar>EDITOR</envar> if
<envar>VISUAL</envar> is not set) environment variable is set
to something sensible.</para>
<envar>VISUAL</envar> (or <envar>EDITOR</envar> if
<envar>VISUAL</envar> is not set) environment variable is set
to something sensible.</para>
<para>You should also make sure that mail delivery works fine.
&man.send-pr.1; uses mail messages for the submission and
@ -486,14 +490,14 @@
<para>Also note that while including small patches in a PR is
generally all right&mdash;particularly when they fix the problem
described in the PR&mdash;large patches and especially new code
which may require substantial review before committing should
be placed on a web or ftp server, and the URL should be
included in the PR instead of the patch. Patches in email
tend to get mangled, especially when GNATS is involved, and
the larger the patch, the harder it will be for interested
parties to unmangle it. Also, posting a patch on the web
allows you to modify it without having to resubmit the entire
patch in a followup to the original PR.</para>
which may require substantial review before committing should
be placed on a web or ftp server, and the URL should be
included in the PR instead of the patch. Patches in email
tend to get mangled, especially when GNATS is involved, and
the larger the patch, the harder it will be for interested
parties to unmangle it. Also, posting a patch on the web
allows you to modify it without having to resubmit the entire
patch in a followup to the original PR.</para>
<para>You should also take note that unless you explicitly
specify otherwise in your PR or in the patch itself, any
@ -822,16 +826,16 @@
<para>The easiest way is to use the followup link on
the individual PR's web page, which you can reach from the
<ulink URL="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
PR search page</ulink>. Clicking on this link will bring up an
PR search page</ulink>. Clicking on this link will bring up an
an email window with the correct To: and Subject: lines filled in
(if your browser is configured to do this).</para>
</listitem>
<listitem>
<para>Alternatively, you can just mail it to
<email>bug-followup@FreeBSD.org</email>, making sure that the
tracking number is included in the subject so the bug tracking
system will know what problem report to attach it to.</para>
<email>bug-followup@FreeBSD.org</email>, making sure that the
tracking number is included in the subject so the bug tracking
system will know what problem report to attach it to.</para>
<note>
<para>If you do <emphasis>not</emphasis> include the tracking