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