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

Source string Read only

(itstool) path: section/para
Context English State
Assigned PRs
If a PR has the <literal>responsible</literal> field set to the username of a FreeBSD developer, it means that the PR has been handed over to that particular person for further work.
Assigned PRs should not be touched by anyone but the assignee or bugmeister. If you have comments, submit a followup. If for some reason you think the PR should change state or be reassigned, send a message to the assignee. If the assignee does not respond within two weeks, unassign the PR and do as you please.
Duplicate PRs
If you find more than one PR that describe the same issue, choose the one that contains the largest amount of useful information and close the others, stating clearly the number of the superseding PR. If several PRs contain non-overlapping useful information, submit all the missing information to one in a followup, including references to the others; then close the other PRs (which are now completely superseded).
Stale PRs
A PR is considered stale if it has not been modified in more than six months. Apply the following procedure to deal with stale PRs:
If the PR contains sufficient detail, try to reproduce the problem in <literal>-CURRENT</literal> and <literal>-STABLE</literal>. If you succeed, submit a followup detailing your findings and try to find someone to assign it to. Set the state to <quote>analyzed</quote> if appropriate.
If the PR describes an issue which you know is the result of a usage error (incorrect configuration or otherwise), submit a followup explaining what the originator did wrong, then close the PR with the reason <quote>User error</quote> or <quote>Configuration error</quote>.
If the PR describes an error which you know has been corrected in both <literal>-CURRENT</literal> and <literal>-STABLE</literal>, close it with a message stating when it was fixed in each branch.
If the PR describes an error which you know has been corrected in <literal>-CURRENT</literal>, but not in <literal>-STABLE</literal>, try to find out when the person who corrected it is planning to MFC it, or try to find someone else (maybe yourself?) to do it. Set the state to <quote>patched</quote> and assign it to whomever will do the MFC.
In other cases, ask the originator to confirm if the problem still exists in newer versions. If the originator does not reply within a month, close the PR with the notation <quote>Feedback timeout</quote>.
Non-Bug PRs
Developers that come across PRs that look like they should have been posted to <link xlink:href="">freebsd-bugs</link> or some other list should close the PR, informing the submitter in a comment why this is not really a PR and where the message should be posted.
The email addresses that Bugzilla listens to for incoming PRs have been published as part of the FreeBSD documentation, have been announced and listed on the web-site. This means that spammers found them.
Whenever you close one of these PRs, please do the following:
Set the component to <literal>junk</literal> (under <literal>Supporting Services</literal>.
Set Responsible to <literal></literal>.
Set State to <literal>Issue Resolved</literal>.
Setting the category to <literal>junk</literal> makes it obvious that there is no useful content within the PR, and helps to reduce the clutter within the main categories.
Further Reading
This is a list of resources relevant to the proper writing and processing of problem reports. It is by no means complete.
<link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/problem-reports/article.html">How to Write FreeBSD Problem Reports</link>—guidelines for PR originators.


No matching activity found.

Browse all component changes

Source information

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