diff options
-rw-r--r-- | en_US.ISO8859-1/articles/problem-reports/article.xml | 35 |
1 files changed, 17 insertions, 18 deletions
diff --git a/en_US.ISO8859-1/articles/problem-reports/article.xml b/en_US.ISO8859-1/articles/problem-reports/article.xml index 66e0520643..d9a7c54f40 100644 --- a/en_US.ISO8859-1/articles/problem-reports/article.xml +++ b/en_US.ISO8859-1/articles/problem-reports/article.xml @@ -101,30 +101,29 @@ for an answer, consider posing the question to the &a.questions;.</para> - <para>Some cases where it may be appropriate to submit a problem - report about something that is not a bug are:</para> + <para>Consider these factors when submitting PRs about ports or + other software that is not part of &os; itself:</para> <itemizedlist> <listitem> - <para>Notification of updates to externally maintained - software (such as ports or software in the contrib/ - directory).</para> + <para>Please do not submit problem reports that simply state + that a newer version of an application is available. Ports + maintainers are automatically notified by + <application>portscout</application> when a new version of + an application becomes available. Actual patches to update + a port to the latest version are welcome.</para> + </listitem> + <listitem> <para>For unmaintained ports (<varname>MAINTAINER</varname> - contains <literal>ports@FreeBSD.org</literal>), such update - notifications 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 - manner.</para> - - <para>If the port is maintained, PRs announcing new upstream - releases are usually not very useful 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.</para> + is <literal>ports@FreeBSD.org</literal>), + a PR without an included patch is unlikely to get picked up + by a committer. To become the maintainer of an + unmaintained port, submit a PR with the request (patch + preferred but not required).</para> + </listitem> + <listitem> <para>In either case, following the process described in <link xlink:href="&url.books.porters-handbook;/port-upgrading.html">Porter's Handbook</link> will yield the best results. (You might |