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
The problem has been reviewed and a solution is being sought.
Further work requires additional information from the originator or the community; possibly information regarding the proposed solution.
A patch has been committed, but something (MFC, or maybe confirmation from originator) is still pending.
The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to take on. If the problem cannot be solved at all, it will be closed, rather than suspended. The documentation project uses <quote>suspended</quote> for <quote>wish-list</quote> items that entail a significant amount of work which no one currently has time for.
A problem report is closed when any changes have been integrated, documented, and tested, or when fixing the problem is abandoned.
The <quote>patched</quote> state is directly related to feedback, so you may go directly to <quote>closed</quote> state if the originator cannot test the patch, and it works in your own testing.
Types of Problem Reports
While handling problem reports, either as a developer who has direct access to the Problem Reports database or as a contributor who browses the database and submits followups with patches, comments, suggestions or change requests, you will come across several different types of PRs.
<link linkend="pr-unassigned">PRs not yet assigned to anyone.</link>
<link linkend="pr-assigned">PRs already assigned to someone.</link>
<link linkend="pr-dups">Duplicates of existing PRs.</link>
<link linkend="pr-stale">Stale PRs</link>
<link linkend="pr-misfiled-notpr">Non-Bug PRs</link>
The following sections describe what each different type of PRs is used for, when a PR belongs to one of these types, and what treatment each different type receives.
Unassigned PRs
When PRs arrive, they are initially assigned to a generic (placeholder) assignee. These are always prepended with <literal>freebsd-</literal>. The exact value for this default depends on the category; in most cases, it corresponds to a specific FreeBSD mailing list. Here is the current list, with the most common ones listed first:
Default Assignees — most common
Default Assignee
base system
bin, conf, gnu, kern, misc
alpha, amd64, arm, i386, ia64, powerpc, sparc64
ports collection


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/pr-guidelines.pot, string 44