Changeset View
Standalone View
en_US.ISO8859-1/articles/problem-reports/article.xml
Show First 20 Lines • Show All 95 Lines • ▼ Show 20 Lines | <para>So how does one determine what is a bug and what is not? As | ||||
a simple rule of thumb, the problem is <emphasis>not</emphasis> | a simple rule of thumb, the problem is <emphasis>not</emphasis> | ||||
a bug if it can be expressed as a question (usually of the form | a bug if it can be expressed as a question (usually of the form | ||||
<quote>How do I do X?</quote> or <quote>Where can I find | <quote>How do I do X?</quote> or <quote>Where can I find | ||||
Y?</quote>). It is not always quite so black and white, but the | Y?</quote>). It is not always quite so black and white, but the | ||||
question rule covers a large majority of cases. When looking | question rule covers a large majority of cases. When looking | ||||
for an answer, consider posing the question to the | for an answer, consider posing the question to the | ||||
&a.questions;.</para> | &a.questions;.</para> | ||||
<para>Some cases where it may be appropriate to submit a problem | <para>Consider these factors when submitting PRs about ports or | ||||
report about something that is not a bug are:</para> | other software that is not part of &os; itself:</para> | ||||
wblock: s/FreeBSD/&os;/ | |||||
Not Done Inline ActionsThe aside makes this confusing, and it's hard to tell what this sentence means. I think it means this: Consider these factors when submitting PRs about ports or other software that is not part of &os; itself: wblock: The aside makes this confusing, and it's hard to tell what this sentence means. I think it… | |||||
<itemizedlist> | <itemizedlist> | ||||
<listitem> | <listitem> | ||||
<para>Notification of updates to externally maintained | <para>Please do not submit problem reports that simply state | ||||
software (such as ports or software in the contrib/ | that a newer version of an application is available. Ports | ||||
directory).</para> | maintainers are automatically notified by | ||||
<application>portscout</application> when a new version of | |||||
an application becomes available. Actual patches to update | |||||
Not Done Inline ActionsThe "feel free" can be taken as kind of passive-aggressive. Could be Actual patches to update a port to a newer version are welcome. wblock: The "feel free" can be taken as kind of passive-aggressive. Could be
Actual patches to update… | |||||
a port to the latest version are welcome.</para> | |||||
</listitem> | |||||
<listitem> | |||||
<para>For unmaintained ports (<varname>MAINTAINER</varname> | <para>For unmaintained ports (<varname>MAINTAINER</varname> | ||||
contains <literal>ports@FreeBSD.org</literal>), such update | is <literal>ports@FreeBSD.org</literal>), | ||||
notifications might get picked up by an interested | a PR without an included patch is unlikely to get picked up | ||||
committer, or you might be asked to provide a patch to | by a committer. To become the maintainer of an | ||||
Not Done Inline ActionsThis second "automatically" is redundant. wblock: This second "automatically" is redundant. | |||||
Not Done Inline Actionss/If you would like to/To/ wblock: s/If you would like to/To/ | |||||
update the port; providing it upfront will greatly improve | unmaintained port, submit a PR with the request (patch | ||||
Not Done Inline ActionsPassive->active: Split sentences apart: applications. So a PR only creates wblock: Passive->active:
s/would only create/only creates/
Split sentences apart:
applications. So a… | |||||
Not Done Inline Actionssuggest changing from: I think we prefer "make me maintainer" requests via bugzilla over mail list, and we definitely want to be sure any new maintainer has a bugzilla account as a minimum requirement to be a maintainer. marino: suggest changing from:
"of an application, contact &a.ports;"
to
"of an unmaintained port… | |||||
your chances that the port will get updated in a timely | preferred but not required).</para> | ||||
Not Done Inline Actions"Supplementary" has a positive connotation. "needless additional" is better. "the committers" can just be "committers". wblock: "Supplementary" has a positive connotation. "needless additional" is better.
"the committers"… | |||||
manner.</para> | </listitem> | ||||
Not Done Inline ActionsThis is a run-on sentence. Break it after "helpful": ...helpful. Maintainers... wblock: This is a run-on sentence. Break it after "helpful":
...helpful. Maintainers... | |||||
Not Done Inline Actionss/contains/is/ wblock: s/contains/is/ | |||||
<para>If the port is maintained, PRs announcing new upstream | <listitem> | ||||
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> | |||||
<para>In either case, following the process described in <link | <para>In either case, following the process described in <link | ||||
xlink:href="&url.books.porters-handbook;/port-upgrading.html">Porter's | xlink:href="&url.books.porters-handbook;/port-upgrading.html">Porter's | ||||
Handbook</link> will yield the best results. (You might | Handbook</link> will yield the best results. (You might | ||||
also wish to read <link | also wish to read <link | ||||
xlink:href="&url.articles.contributing-ports;/article.html">Contributing | xlink:href="&url.articles.contributing-ports;/article.html">Contributing | ||||
to the FreeBSD Ports Collection</link>.)</para> | to the FreeBSD Ports Collection</link>.)</para> | ||||
</listitem> | </listitem> | ||||
</itemizedlist> | </itemizedlist> | ||||
▲ Show 20 Lines • Show All 1,097 Lines • Show Last 20 Lines |
s/FreeBSD/&os;/