Source string Read only

(itstool) path: row/entry
10/100
Context English State
perl
port which is maintained by python@FreeBSD.org
freebsd-python
port which is maintained by ruby@FreeBSD.org
freebsd-ruby
port which is maintained by secteam@FreeBSD.org
secteam
port which is maintained by vbox@FreeBSD.org
vbox
port which is maintained by x11@FreeBSD.org
freebsd-x11
Ports PRs which have a maintainer who is a ports committer may be reassigned by anyone (but note that not every FreeBSD committer is necessarily a ports committer, so you cannot simply go by the email address alone.)
For other PRs, please do not reassign them to individuals (other than yourself) unless you are certain that the assignee really wants to track the PR. This will help to avoid the case where no one looks at fixing a particular problem because everyone assumes that the assignee is already working on it.
Common Assignees — Other
problem with PR database
bugmeister
problem with Bugzilla <link xlink:href="https://bugs.freebsd.org/submit/">web form</link>.
doc
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

Loading…

No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: row/entry
Flags
read-only
Source string location
article.translate.xml:729 article.translate.xml:736
String age
a year ago
Source string age
a year ago
Translation file
articles/pr-guidelines.pot, string 184