Index: en_US.ISO8859-1/articles/problem-reports/article.xml
===================================================================
--- en_US.ISO8859-1/articles/problem-reports/article.xml
+++ en_US.ISO8859-1/articles/problem-reports/article.xml
@@ -101,30 +101,33 @@
for an answer, consider posing the question to the
&a.questions;.
- Some cases where it may be appropriate to submit a problem
- report about something that is not a bug are:
+ When submitting a PR about externally maintained software
+ (such as ports or software in the contrib/ directory) consider
+ the following:
- Notification of updates to externally maintained
- software (such as ports or software in the contrib/
- directory).
-
For unmaintained ports (MAINTAINER
- contains ports@FreeBSD.org), such update
- notifications might get picked up by an interested
+ contains ports@FreeBSD.org),
+ a PR about a new update
+ might get picked up by an interested
committer, or you might be asked to provide a patch to
update the port; providing it upfront will greatly improve
- your chances that the port will get updated in a timely
+ the chances that the port will get updated in a timely
manner.
+
+ If the port is maintained, PRs announcing new upstream
- releases are usually not very useful since they generate
+ releases are usually not very helpfuk since they generate
supplementary work for the committers, and the maintainer
- likely knows already there is a new version, they have
- probably worked with the developers on it, they are probably
- testing to see there is no regression, etc.
+ likely knows already there is a new version. The &os;
+ project uses portscout to
+ automatically track when new versions of applications are
+ released, and notify the maintainers automatically.
+
+ In either case, following the process described in Porter's
Handbook will yield the best results. (You might