48a016649c
- contributing-ports moved into contributing - OpenBSM redirects to TrustedBSD which is the entry immediately below. - cvsweb is no longer maintained by the FreeBSD project - TET integration is obsolete (per the wiki). Linking to the newer project is left to a future commi - binary-update refers to an older version of freebsd-update. This is now documented in the handbook. - vinum redirects to to an ad website - Tertiary Disk - http://now.cs.berkeley.edu/Td/ is unreachable. - OpenJDK 6 is not frequently updated. While its still available it is also EoL so just stop referencing it.
236 lines
11 KiB
XML
236 lines
11 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
|
|
"http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [
|
|
<!ENTITY title "Policies of the Ports Management Team">
|
|
]>
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<title>&title;</title>
|
|
|
|
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
|
|
</head>
|
|
|
|
<body class="navinclude.about">
|
|
|
|
<p>In accordance with its <a href="charter.html">Charter</a>, the
|
|
Ports Management Team has adopted certain policies to try to meet
|
|
each of its goals.</p>
|
|
|
|
<p><a href="policies_eol.html">EOL Policies of Ports and Ports
|
|
Intrastructure</a></p>
|
|
|
|
<h3>Assure The Integrity Of The Ports Collection</h3>
|
|
|
|
<p>To help assure the integrity of the Ports Collection, portmgr
|
|
acts as sole committer for certain files that are integral to it,
|
|
such as <tt>bsd.port.mk</tt>. Since the ports tree is not
|
|
branched (unlike some of the other BSD projects), any fatal
|
|
error in these files will be quickly picked up by the many
|
|
users who run automated updates of their ports.</p>
|
|
|
|
<p>portmgr also runs periodic builds of proposed large changes to the
|
|
Ports Collection on a dedicated area of the automated
|
|
<a href="https://pkg-status.freebsd.org">ports building cluster</a>.
|
|
These are termed experimental builds (often referred to as "exp-runs").
|
|
Examples of changes that should be tested here before committing
|
|
include:</p>
|
|
|
|
<ul>
|
|
<li><p>changes to <tt>bsd.port.mk</tt></p></li>
|
|
<li><p>changes to packages with many dependencies, including
|
|
X11 servers, GNOME, KDE, autotools, and so forth</p></li>
|
|
<li><p>changes that change the "accepted best practice" for
|
|
ports Makefiles, such as definitions or usage of common make
|
|
variables (or <tt>Makevar</tt>s). (e.g., consolidation of
|
|
various implementations of USE_*, WITH_*, and so forth)</p></li>
|
|
<li><p>large changes to the repository (such as when an existing port category
|
|
is divided up)</p></li>
|
|
</ul>
|
|
|
|
<p>Any large-scale
|
|
failures that might be caused by any of the above need to be caught
|
|
first before a large number of user installations are affected.</p>
|
|
|
|
<p>At other times, especially during the preparations for a new release,
|
|
there are <a href="policies_committing.html">
|
|
other restrictions on when commits are allowed</a>.</p>
|
|
|
|
<p>portmgr reserves the right to act as final arbiter of other
|
|
commits in certain unusual cases, such as: commits that in their
|
|
opinion destabilize the Ports Collection; violate the
|
|
Principle Of Least Astonishment for FreeBSD's users; or in cases
|
|
of inter-committer disputes that cannot be solved among the
|
|
committers themselves.</p>
|
|
|
|
<h3>Maintain The Automated Ports Building Cluster</h3>
|
|
|
|
<p>portmgr maintains a set of machines that automatically build
|
|
packages on combinations of FreeBSD source tree versus CPU
|
|
architecture (in our terminology, <tt>build environments</tt> or
|
|
<tt>buildenv</tt>s). Where license distribution permits, the
|
|
resulting packages are regularly uploaded to the main FTP mirror
|
|
as the "new latest package" so that they are available for download
|
|
by FreeBSD users. Port build failures are reported to the responsible
|
|
maintainers and/or committers for the appropriate corrective action.</p>
|
|
|
|
<p>In some cases ports may become broken by changes to the FreeBSD base
|
|
system (src/ tree). In such a case, the Ports Management Team expects
|
|
the responsible Source Committer to develop fixes to the affected ports,
|
|
in consultation with the relevant port maintainers.</p>
|
|
|
|
<h3>Work With The FreeBSD Security Team</h3>
|
|
|
|
<!-- nothing specific; the header is left to cross-reference the charter -->
|
|
|
|
<h3>Work with FreeBSD Ports and Documentation Committers</h3>
|
|
|
|
<p>portmgr will attempt to help keep the
|
|
<a href="&base;/doc/en_US.ISO8859-1/books/porters-handbook/index.html">
|
|
FreeBSD Porter's Handbook</a> up to date with what it believes to be
|
|
the "best practices" for individual ports.</p>
|
|
|
|
<p>(The intent is not just to lay down 'rules' but to say 'here is
|
|
why something that we advocate as The Right Thing in the ports
|
|
Makefiles is done.' In particular, there are a number of
|
|
"edge cases" that <tt>bsd.*.mk</tt> has some very convoluted
|
|
code to handle -- such as ensuring that ports can be installed
|
|
from CD-ROM, over NFS, and so forth -- and failing to understand
|
|
these issues can lead to maintainers using shortcuts that will
|
|
not work in these edge cases.)</p>
|
|
|
|
<p>portmgr is not the sole owner of the Porter's Handbook, as it is
|
|
actually in the <tt>doc/</tt> tree. We welcome PR submitters and
|
|
<tt>doc</tt> committers to work on it to add documentation that helps
|
|
to clarify existing practice. However, we would like to request,
|
|
as a courtesy, the right to review any changes that would seem to
|
|
change existing practice.</p>
|
|
|
|
<p>In addition, there has been recent discussion about creating a
|
|
"Rights And Responsibilities of FreeBSD Ports Maintainers and Committers"
|
|
document. portmgr supports this effort and looks forward to being
|
|
able to review any drafts.</p>
|
|
|
|
<p>portmgr also is responsible for certain other documentation such as
|
|
the ports-specific portions of the
|
|
<a href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/ports.html">
|
|
Committer's Guide</a> and the
|
|
<a href="&base;/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html">
|
|
Contributing to FreeBSD Guide</a>.</p>
|
|
|
|
<h3>Respect The Legal Rights Of Authors Whose Works Are Installed Via
|
|
The Ports Collection</h3>
|
|
|
|
<p>To the extent possible with a volunteer project, portmgr will work
|
|
to ensure that the legal rights of authors whose works are installed
|
|
via the Ports Collection are respected. This includes making sure that
|
|
the appropriate entries are made to <tt>ports/LEGAL</tt> and to
|
|
the <tt>makevars</tt> that control package building and thus automated
|
|
distribution of binaries.</p>
|
|
|
|
<p>In rare cases this may also require removing a port and all distfiles
|
|
and binaries if the original author demands it.</p>
|
|
|
|
<p>portmgr asks our volunteer committers to carefully consider authors'
|
|
licensing restrictions when committing new ports, since it is infeasible
|
|
for the members of portmgr to do so themselves due to the huge number
|
|
of ports.</p>
|
|
|
|
<h3>Act As Arbiter Of First Resort For Disputes Between FreeBSD
|
|
Community Members Such As Maintainers And Committers</h3>
|
|
|
|
<p>portmgr encourages members of the FreeBSD community to work
|
|
together in accordance with the principles set out in the
|
|
Committer's Guide. In case of disputes, it reserves the right
|
|
to abitrate, subject to review by the Core Team.</p>
|
|
|
|
<h3>Manage Commit Access To The Ports Tree</h3>
|
|
|
|
<p>The FreeBSD Core Team has delegated the responsibility to manage
|
|
commit access to the <tt>ports/</tt> tree to portmgr. Core
|
|
reviews granting and revocation of commit bits and has final
|
|
authority over all the entire FreeBSD repositories.</p>
|
|
|
|
<p>New Ports Committers are proposed by an existing Ports Committer
|
|
who wishes to act as a mentor. The proposals should include a brief
|
|
summary of the history of contributions made by the proposed new
|
|
committer such as number of PRs submitted, number of ports currently
|
|
maintained, and existing commit bits in other trees, if any.</p>
|
|
|
|
<p>In its votes the team will consider that history as well as any other
|
|
relevant factors. The results of the votes are made available to
|
|
the FreeBSD developer community.</p>
|
|
|
|
<p>In accordance with practice elsewhere in the project, inactive
|
|
Ports Committers are
|
|
<a href="policies_contributors.html#commit_privileges">
|
|
periodically contacted</a> to enquire about
|
|
their status and interest in continuing to work with the ports tree.
|
|
Committers who do not respond to such email, or who respond in the
|
|
negative, have their commit bits reclaimed for safekeeping.
|
|
Currently, this period is one year.</p>
|
|
|
|
<p>In unusual cases it may become necessary to remove Ports Committers
|
|
for other reasons. This will only be done after serious deliberation,
|
|
and is subject to review by Core.</p>
|
|
|
|
<h3>Establish Guidelines And Policies Governing The Rights And
|
|
Responsibilities Of Ports Committers And Maintainers</h3>
|
|
|
|
<p>portmgr has the responsibility to establish guidelines and policies
|
|
governing the rights and responsibilities of Ports Committers and
|
|
maintainers, such as expected standards of maintainership, conditions
|
|
under which maintainers may be overridden or removed, and other
|
|
policies.</p>
|
|
|
|
<p>To ensure that ports Problem Reports are handled in a timely
|
|
manner, portmgr has established a guideline about how long a PR
|
|
assigned to a committer may remain open before being eligible for
|
|
being committed by another committer via a
|
|
<a href="policies_contributors.html#pr_timeout">"maintainer timeout"</a>.
|
|
This time period applies to such things as updates that do not require
|
|
a regression run; for other updates, please contact portmgr directly.
|
|
The time period does not count ports freezes and
|
|
generally recognized holidays.</p>
|
|
|
|
<p>In addition, to ensure that ports are maintained in a timely
|
|
fashion, portmgr has established a guideline about how long a port
|
|
maintainer may be inactive before
|
|
<a href="policies_contributors.html#maintainer_reset">
|
|
forfeiting maintainership</a>.
|
|
"inactive" is not interpreted strictly, but is intended to encompass
|
|
such things as unresolved open PRs, commits made by others via
|
|
maintainer timeouts, and unresolved build problems.</p>
|
|
|
|
<p>The intent of these policies is not to assign punishment or blame,
|
|
but to reflect the fact that the software installed by the Ports
|
|
Collection undergoes rapid development that is outside FreeBSD's
|
|
control. Part of the responsibility that a ports maintainer
|
|
accepts is to try to keep a port working and as up-to-date as
|
|
feasible. It is unfair to our users to let unfixed problems
|
|
languish and stale versions remain. However, we also recognize
|
|
that all of our maintainers and committers are volunteers just
|
|
as we are, and that as with any volunteer project, it is easy to
|
|
overcommit, or lose interest in a particular port.</p>
|
|
|
|
<p>Maintainers and committers who feel overcommitted or have lost
|
|
interest in any particular port should feel free to ask for new
|
|
volunteers and/or reassignment of the port back to the general
|
|
pool. Not only will this help keep the Ports Collection current,
|
|
but hopefully will help prevent volunteer burnout.</p>
|
|
|
|
<h3>Help Prioritize Future Directions For The Overall Ports Collection</h3>
|
|
|
|
<p>portmgr recognizes that the development and evolution of the Ports
|
|
Collection is primarily driven by the work of community members.
|
|
However, due to the unbranched nature of the Ports Collection,
|
|
it is sometimes necessary to coordinate, or even choose among, any
|
|
proposed changes.</p>
|
|
|
|
<p>To some extent this involves choosing which patches are adopted
|
|
for testing on the build cluster, but it also involves such issues
|
|
as working to build consensus over architectural decisions,
|
|
creating lists of "interesting projects", and so forth.</p>
|
|
|
|
</body>
|
|
</html>
|