Discusses the goals, rights, and responsibilities of the team. The contents of this document are approved by the FreeBSD Core Team.
-== link:policies[Policies]
+== link:policies/[Policies]
-Discusses current policies that the team has adopted to meet its goals, such as link:policies_contributors[timeouts for inactivity] and link:policies_committing[when commits are allowed]. Also contains link:policies_eol[the policy for supported releases and branches].
+Discusses current policies that the team has adopted to meet its goals, including link:policies/integrity[collection integrity], link:policies/committing[when commits are allowed], link:policies/contributors[timeouts for inactivity], and link:policies/eol[supported releases and branches].
+In accordance with its link:../charter[Charter], the Ports Management Team has adopted the following policies to guide development and maintenance of the FreeBSD Ports Collection.
+The link:../implementation[Implementation Issues Involving the Ports Collection] document explains the rationale behind many of these policies, including why the ports tree is unbranched and why certain changes require regression testing.
+title: "Ports Management Policy: Committing to the Tree"
+sidenav: about
+---
+
+= Committing to the Ports Tree
+
+These policies govern when and under what conditions commits to the ports tree are permitted.
+
+== Changes to bsd.port.mk
+
+Portmgr acts as sole committer for `bsd.port.mk` at all times. All proposed changes must be submitted as problem reports and assigned to portmgr. See link:integrity[Ensuring Ports Collection Integrity] for approval requirements.
+
+== When the Tree is Open
+
+Commits are accepted for changes that do not require a link:integrity#requires_regression_test[regression test].
+
+== When the Tree is Frozen
+
+During release preparation, the tree is frozen and all commits require portmgr approval. Only the following changes are generally accepted during freeze:
+
+* Fixes that prevent ports from installing, deinstalling, or running properly for the upcoming release
+* Security fixes
+* Licensing issues (which may require a slipped release tag)
+
+== When the Tree is Thawed
+
+After a release, during the period before packages are rebuilt, no link:integrity#sweeping_changes[sweeping changes] are permitted. This prevents the need to rebuild all release packages.
+title: "Ports Management Policy: Maintainers and Committers"
+sidenav: about
+---
+
+= Maintainers and Committers
+
+These policies establish time periods and expectations for maintainer and committer responses to issues.
+
+== Problem Report Timeouts
+
+The time limit for a port maintainer to respond to a problem report (PR) is two weeks. After that period:
+
+* For minor changes, any ports committer may commit the change
+* For major changes (e.g., those requiring a regression run), contact portmgr first
+
+The auto-assigner system attempts to notify maintainers, but its success depends on the PR summary containing the category/portname. Before declaring a timeout, verify that the maintainer was actually notified by checking the PR audit trail and CC lines.
+
+== Maintainer Reset
+
+A maintainer who does not respond to port issues for three months may be reset by any ports committer. If you are uncertain whether resetting a maintainer is appropriate, contact portmgr.
+
+This period may be shortened by portmgr if the email address returns a hard bounce. In such cases, it is advisable to reset all the maintainer's ports and check the status of any open PRs.
+
+== Commit Privileges
+
+Ports committers who are inactive for one year will have their commit privileges reclaimed. Portmgr will contact the committer by email before invoking this limit.
+title: "Ports and Packages for Supported Releases"
+sidenav: about
+---
+
+include::shared/en/urls.adoc[]
+
+= Ports and Packages for Supported Releases
+
+== Support Policy
+
+Support of FreeBSD releases by ports and the ports infrastructure matches the policies set out by the link:../../security/#sup[FreeBSD Security Officer].
+
+Once a major branch reaches its end-of-life (EOL) date, a "last known good" ports tree is tagged with `RELEASE_X_EOL` as a convenience for users who intend to self-support their installations. This tag receives no support and security fixes are not applied. Its use is discouraged and should only be considered as a last resort.
+
+== Quality Assurance
+
+For all supported major src branches, all ports are included in an automated quality assurance procedure which builds, installs, packages, and deinstalls each port on all link:{committers-guide}#AEN1259[Tier 1 platforms].
+
+Maintainers and committers are notified of failures detected during testing. Ports that are known not to build or run on a given supported branch and/or platform are marked accordingly.
+
+== Prebuilt Packages
+
+Prebuilt binary packages are provided for all major branches and Tier 1 platforms via link:{committers-guide}[pkg(8)].
+
+Package builds use the oldest supported minor release within each major branch to ensure ABI and KBI backwards compatibility, supporting all minor versions of each branch including `-RELEASE` and `-STABLE`.
+
+== Current Supported Releases
+
+The current package sets and estimated lifetimes of supported branches are as follows. The _Estimated EoL_ column gives the earliest date on which that branch is likely to be dropped.
+Older releases are not maintained. Ports and packages may not install or run on them. Users are strongly encouraged to upgrade to a supported release.
+The Ports Collection is unbranched, unlike the src tree. This design choice is both a constraint and a risk: any fatal error in the ports framework immediately affects thousands of users running daily updates. These policies exist to catch problems early.
+
+== Changes to bsd.port.mk
+
+Portmgr acts as sole committer for `bsd.port.mk` at all times. Proposed changes must be submitted as problem reports (PRs) and assigned to portmgr.
+
+Except in unusual cases, approval for changes is only granted after a regression test has been run on the dedicated automated ports building cluster. Typically, a dozen or more proposed changes are tested simultaneously, and only after a build of the entire ports tree succeeds will portmgr commit the changes.
+
+== Changes Requiring Regression Testing
+
+Changes beyond `bsd.port.mk` can have drastic effects on the tree. The following types of changes require testing on the cluster before committing:
+
+* Changes to packages with many dependencies, including X11 servers, GNOME, KDE, gettext, autotools, and similar infrastructure packages
+* Changes that alter accepted best practices for ports Makefiles, such as definitions or usage of common make variables (`USE_*`, `WITH_*`, etc.)
+* Large repository copies, such as when an existing port category is divided
+
+If you are unsure whether your proposed change requires regression testing, contact portmgr@FreeBSD.org before committing.
+
+== Sweeping Changes
+
+A "sweeping change" is a commit that affects a non-trivial number of packages such that any other change (like fixing a single security problem) would require a complete rebuild of packages, delaying the release potentially by weeks.
+
+Examples of sweeping changes:
+
+* Any commit to `bsd.*.mk`
+* Anything else that normally requires a regression test (see above)
+* Shared library version bumps
+* Repository copies involving multiple ports
+
+The following do NOT constitute sweeping changes:
+
+* Commits to leaf ports (ports upon which no other port depends)
+* Cosmetic changes not affecting the package (e.g., changes to `pkg_descr`)
+* New ports
+* Repository copies of individual ports
+
+When in doubt, ask portmgr before committing.
+
+== Automated Build Cluster
+
+Portmgr maintains automated build machines that continually build packages on all combinations of FreeBSD source tree and CPU architecture. These build environments are essential for identifying failures before they reach users.
+
+Maintainers and committers are notified of build failures and are expected to fix affected ports. Port build failures are reported to responsible maintainers and/or committers for corrective action.
+
+In cases where ports break due to changes in the FreeBSD base system (src tree), the responsible Source Committer is expected to develop and commit fixes in consultation with relevant port maintainers.
+
+== Dispute Resolution
+
+Portmgr reserves the right to act as final arbiter in cases where:
+
+* Commits appear to destabilize the Ports Collection
+* Commits violate the Principle of Least Astonishment for FreeBSD users
+* Inter-committer disputes cannot be resolved among committers themselves
+
+These determinations are subject to review by the FreeBSD Core Team.
+= Quality Assurance Tasks for the Ports Management Team
+
+The Ports Management Team undertakes several QA activities to improve Ports Collection quality. These fall into two categories: activities during the release cycle and activities between releases.
+
+== Activities During a Release Cycle
+
+* Work with the link:../../releng/[Release Engineering Team] to coordinate the release schedule
+* Determine which prebuilt packages can be included on default install ISOs
+* Cut over to a new quarterly branch
+
+== Activities Between Release Cycles
+
+=== Build Cluster Management
+
+Portmgr maintains machines that automatically build packages on all combinations of FreeBSD release and CPU architecture (known as `build environments` or `buildenvs`).
+
+These builds produce error logs for packages that do not build correctly. Periodically, the team marks broken ports so that maintainers are notified.
+
+Successfully built packages (those freely redistributable) are copied to the primary FTP server and become the default "latest package" for installations using packages rather than ports.
+
+=== Community Notifications
+
+Portmgr notifies the FreeBSD community of problems within the Ports Collection:
+
+* Public list of ports to be removed due to security, build failures, or obsolescence
+* Private email to maintainers of affected ports
+* Private email to maintainers of ports already marked BROKEN and/or FORBIDDEN
+* Private email to non-committer maintainers with open PRs (to flag PRs they may not know about)
+* Public email about commits that break INDEX builds
+* Public email about commits that send revision metadata backwards
+* Private courtesy notification when a port is about to be marked BROKEN
+
+=== Port Expiration
+
+Ports are marked DEPRECATED with an EXPIRATION_DATE when they become unmaintained or broken. If not fixed by the expiration date, they are removed.
+
+The EXPIRATION_DATE should generally be set at least two months in the future to allow sufficient upgrade time.
+
+In cases where a port is replaced by a newer version, it is marked DEPRECATED when the older version is no longer maintained upstream.