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:
Mathieu Arnold 2014-07-04 16:47:12 +00:00
parent f09ae4a8a7
commit afc56f9a3a
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=45207

View file

@ -2719,21 +2719,66 @@ ALWAYS_KEEP_DISTFILES= yes
<!-- smiley-->
<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
used should be <literal>user@hostname.domain</literal>. Please
do not include any descriptive text such as your real name in
this entry&mdash;that merely confuses
<filename>bsd.port.mk</filename>.</para>
used is <literal>user@hostname.domain</literal>. Please
do not include any descriptive text such as a real name in
this entry. That merely confuses the Ports infrastructure
and most tools using it.</para>
<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
to the <link
to <link
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
maintainer does not respond to an update request after two weeks
(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
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
modified without the maintainer's consent. These kinds of
changes will never affect the port's functionality.</para>