Add portmgr's blanket approval, and update what being a maintainer means.
PH: D342 Reviewed by: wblock, swills, erwin... Sponsored by: Absolight
This commit is contained in:
parent
f09ae4a8a7
commit
afc56f9a3a
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=45207
1 changed files with 56 additions and 10 deletions
|
@ -2719,21 +2719,66 @@ ALWAYS_KEEP_DISTFILES= yes
|
||||||
<!-- smiley-->
|
<!-- smiley-->
|
||||||
<emphasis>:-)</emphasis></para>
|
<emphasis>:-)</emphasis></para>
|
||||||
|
|
||||||
<para>Note that only a single address without the comment part is
|
<para>Only a single address without the comment part is
|
||||||
allowed as a <varname>MAINTAINER</varname> value. The format
|
allowed as a <varname>MAINTAINER</varname> value. The format
|
||||||
used should be <literal>user@hostname.domain</literal>. Please
|
used is <literal>user@hostname.domain</literal>. Please
|
||||||
do not include any descriptive text such as your real name in
|
do not include any descriptive text such as a real name in
|
||||||
this entry—that merely confuses
|
this entry. That merely confuses the Ports infrastructure
|
||||||
<filename>bsd.port.mk</filename>.</para>
|
and most tools using it.</para>
|
||||||
|
|
||||||
<para>The maintainer is responsible for keeping the port up to
|
<para>The maintainer is responsible for keeping the port up to
|
||||||
date, and ensuring the port works correctly. For a detailed
|
date and making sure that it works correctly. For a detailed
|
||||||
description of the responsibilities of a port maintainer, refer
|
description of the responsibilities of a port maintainer, refer
|
||||||
to the <link
|
to <link
|
||||||
xlink:href="&url.articles.contributing-ports;/maintain-port.html">The
|
xlink:href="&url.articles.contributing-ports;/maintain-port.html">The
|
||||||
challenge for port maintainers</link> section.</para>
|
challenge for port maintainers</link>.</para>
|
||||||
|
|
||||||
<para>Changes to the port will be sent to the maintainer of a port
|
<note>
|
||||||
|
<para>A maintainer volunteers to keep a port in good working
|
||||||
|
order. Maintainers have the primary responsibility for their
|
||||||
|
ports, but not exclusive ownership. Ports exist for the
|
||||||
|
benefit of the community and, in reality, belong to the
|
||||||
|
community. What this means is that people other than the
|
||||||
|
maintainer can make changes to a port. Large changes to the
|
||||||
|
Ports Collection might require changes to many ports. The
|
||||||
|
&os; Ports Management Team or members of other teams might
|
||||||
|
modify ports to fix dependency issues or other problems, like
|
||||||
|
a version bump for a shared library update.</para>
|
||||||
|
|
||||||
|
<para>Some types of fixes have <quote>blanket approval</quote>
|
||||||
|
from the &a.portmgr;, allowing any committer to fix those
|
||||||
|
categories of problems on any port. These fixes do not need
|
||||||
|
approval from the maintainer. Blanket approval does not apply
|
||||||
|
to ports that are maintained by teams like <email
|
||||||
|
role="nolink">autotools@FreeBSD.org</email>, <email
|
||||||
|
role="nolink">x11@FreeBSD.org</email>, <email
|
||||||
|
role="nolink">gnome@FreeBSD.org</email>, or <email
|
||||||
|
role="nolink">kde@FreeBSD.org</email>. These teams use
|
||||||
|
external repositories and can have work that would conflict
|
||||||
|
with changes that would normally fall under blanket
|
||||||
|
approval.</para>
|
||||||
|
|
||||||
|
<para>Blanket approval for most ports applies to these types of
|
||||||
|
fixes:</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>Most infrastructure changes to a port (that is,
|
||||||
|
modernizing, but not changing the functionality). For
|
||||||
|
example, converting to staging,
|
||||||
|
<varname>USE_GMAKE</varname> to
|
||||||
|
<literal>USES=gmake</literal>, the new
|
||||||
|
<varname>LIB_DEPENDS</varname> format...</para>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para>Trivial and <emphasis>tested</emphasis> build
|
||||||
|
fixes.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</note>
|
||||||
|
|
||||||
|
<para>Other changes to the port will be sent to the maintainer
|
||||||
for review and approval before being committed. If the
|
for review and approval before being committed. If the
|
||||||
maintainer does not respond to an update request after two weeks
|
maintainer does not respond to an update request after two weeks
|
||||||
(excluding major public holidays), then that is considered a
|
(excluding major public holidays), then that is considered a
|
||||||
|
@ -2748,7 +2793,8 @@ ALWAYS_KEEP_DISTFILES= yes
|
||||||
|
|
||||||
<para>We reserve the right to modify the maintainer's submission
|
<para>We reserve the right to modify the maintainer's submission
|
||||||
to better match existing policies and style of the Ports
|
to better match existing policies and style of the Ports
|
||||||
Collection without explicit blessing from the submitter. Also,
|
Collection without explicit blessing from the submitter or the
|
||||||
|
maintainer. Also,
|
||||||
large infrastructural changes can result in a port being
|
large infrastructural changes can result in a port being
|
||||||
modified without the maintainer's consent. These kinds of
|
modified without the maintainer's consent. These kinds of
|
||||||
changes will never affect the port's functionality.</para>
|
changes will never affect the port's functionality.</para>
|
||||||
|
|
Loading…
Reference in a new issue