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

Source string Read only

(itstool) path: glossentry/glossterm
Context English State
Problem Report State
It is important to update the state of a PR when certain actions are taken. The state should accurately reflect the current state of work on the PR.
A small example on when to change PR state
When a PR has been worked on and the developer(s) responsible feel comfortable about the fix, they will submit a followup to the PR and change its state to <quote>feedback</quote>. At this point, the originator should evaluate the fix in their context and respond indicating whether the defect has indeed been remedied.
A Problem Report may be in one of the following states:
Initial state; the problem has been pointed out and it needs reviewing.
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


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: glossentry/glossterm
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/pr-guidelines.pot, string 36