The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: listitem/para
Context English State
When you file a bug, you will find the following fields:
<emphasis>Summary:</emphasis> Fill this out with a short and accurate description of the problem. The synopsis is used as the subject of the problem report email, and is used in problem report listings and summaries; problem reports with obscure synopses tend to get ignored.
<emphasis>Severity:</emphasis> One of <literal>Affects only me</literal>, <literal>Affects some people</literal> or <literal>Affects many people</literal>. Do not overreact; refrain from labeling your problem <literal>Affects many people</literal> unless it really does. FreeBSD developers will not necessarily work on your problem faster if you inflate its importance since there are so many other people who have done exactly that.
<emphasis>Category:</emphasis> Choose an appropriate category.
The first thing you need to do is to decide what part of the system your problem lies in. Remember, FreeBSD is a complete operating system, which installs both a kernel, the standard libraries, many peripheral drivers, and a large number of utilities (the <quote>base system</quote>). However, there are thousands of additional applications in the Ports Collection. You'll first need to decide if the problem is in the base system or something installed via the Ports Collection.
Here is a description of the major categories:
If a problem is with the kernel, the libraries (such as standard C library <literal>libc</literal>), or a peripheral driver in the base system, in general you will use the <literal>kern</literal> category. (There are a few exceptions; see below). In general these are things that are described in section 2, 3, or 4 of the manual pages.
If a problem is with a binary program such as <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> or <citerefentry><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, you will first need to determine whether these programs are in the base system or were added via the Ports Collection. If you are unsure, you can do <command>whereis <replaceable>programname</replaceable></command>. FreeBSD's convention for the Ports Collection is to install everything underneath <filename class="directory">/usr/local</filename>, although this can be overridden by a system administrator. For these, you will use the <literal>ports</literal> category (yes, even if the port's category is <literal>www</literal>; see below). If the location is <filename class="directory">/bin</filename>, <filename class="directory">/usr/bin</filename>, <filename class="directory">/sbin</filename>, or <filename class="directory">/usr/sbin</filename>, it is part of the base system, and you should use the <literal>bin</literal> category. These are all things that are described in section 1 or 8 of the manual pages.
If you believe that the error is in the startup <literal>(rc)</literal> scripts, or in some kind of other non-executable configuration file, then the right category is <literal>conf</literal> (configuration). These are things that are described in section 5 of the manual pages.
If you have found a problem in the documentation set (articles, books, man pages) or website the correct choice is <literal>docs</literal>.
if you are having a problem with something from a port named <literal>www/<replaceable>someportname</replaceable></literal>, this nevertheless goes in the <literal>ports</literal> category.
There are a few more specialized categories.
If the problem would otherwise be filed in <literal>kern</literal> but has to do with the USB subsystem, the correct choice is <literal>usb</literal>.
If the problem would otherwise be filed in <literal>kern</literal> but has to do with the threading libraries, the correct choice is <literal>threads</literal>.
If the problem would otherwise be in the base system, but has to do with our adherence to standards such as <trademark class="registered">POSIX</trademark>, the correct choice is <literal>standards</literal>.
If you are convinced that the problem will only occur under the processor architecture you are using, select one of the architecture-specific categories: commonly <literal>i386</literal> for Intel-compatible machines in 32-bit mode; <literal>amd64</literal> for AMD machines running in 64-bit mode (this also includes Intel-compatible machines running in EMT64 mode); and less commonly <literal>arm</literal> or <literal>powerpc</literal>.
These categories are quite often misused for <quote>I do not know</quote> problems. Rather than guessing, please just use <literal>misc</literal>.
Correct Use of Arch-Specific Category
You have a common PC-based machine, and think you have encountered a problem specific to a particular chipset or a particular motherboard: <literal>i386</literal> is the right category.
Incorrect Use of Arch-Specific Category
You are having a problem with an add-in peripheral card on a commonly seen bus, or a problem with a particular type of hard disk drive: in this case, it probably applies to more than one architecture, and <literal>kern</literal> is the right category.
If you really do not know where the problem lies (or the explanation does not seem to fit into the ones above), use the <literal>misc</literal> category. Before you do so, you may wish to ask for help on the <link xlink:href="">FreeBSD general questions mailing list</link> first. You may be advised that one of the existing categories really is a better choice.
<emphasis>Environment:</emphasis> This should describe, as accurately as possible, the environment in which the problem has been observed. This includes the operating system version, the version of the specific program or file that contains the problem, and any other relevant items such as system configuration, other installed software that influences the problem, etc.—quite simply everything a developer needs to know to reconstruct the environment in which the problem occurs.
<emphasis>Description:</emphasis>A complete and accurate description of the problem you are experiencing. Try to avoid speculating about the causes of the problem unless you are certain that you are on the right track, as it may mislead a developer into making incorrect assumptions about the problem. It should include the actions you need to take to reproduce the problem. If you know any workaround, include it. It not only helps other people with the same problem work around it, but may also help a developer understand the cause for the problem.
Once the problem report has been filed, you will receive a confirmation by email which will include the tracking number that was assigned to your problem report and a URL you can use to check its status. With a little luck, someone will take an interest in your problem and try to address it, or, as the case may be, explain why it is not a problem. You will be automatically notified of any change of status, and you will receive copies of any comments or patches someone may attach to your problem report's audit trail.
If someone requests additional information from you, or you remember or discover something you did not mention in the initial report, please submit a follow up. The number one reason for a bug not getting fixed is lack of communication with the originator. The easiest way is to use the comment option on the individual PR's web page, which you can reach from the <link xlink:href="">PR search page</link>.
If the problem report remains open after the problem has gone away, just add a comment saying that the problem report can be closed, and, if possible, explaining how or when the problem was fixed.
Sometimes there is a delay of a week or two where the problem report remains untouched, not assigned or commented on by anyone. This can happen when there is an increased problem report backlog or during a holiday season. When a problem report has not received attention after several weeks, it is worth finding a committer particularly interested in working on it.
There are a few ways to do so, ideally in the following order, with a few days between attempting each communication channel:
Find the relevant FreeBSD mailing list for the problem report from the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">list in the Handbook</link> and send a message to that list asking about assistance or comments on the problem report.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: listitem/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/problem-reports.pot, string 95