Source string Read only

(itstool) path: listitem/para
169/1690
Context English State
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="http://lists.FreeBSD.org/mailman/listinfo/freebsd-bugs">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>nobody@FreeBSD.org</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.

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Flags
read-only
Source string location
article.translate.xml:870
String age
a year ago
Source string age
a year ago
Translation file
articles/pr-guidelines.pot, string 209