Quality Assurance Tasks for the Ports Management Team

There are a number of tasks that the Ports Management Team undertakes to try to improve the quality of the Ports Collection. These fall into two main categories: activities during a release cycle and activities between release cycles.

Activities During a Release Cycle

Work with the Release Engineering Team to coordinate the release schedule.
Work with the RE team to determine which pre-built packages can be included on the default install ISOs.
Cut over to the new quarterly branch.

Activities Between Release Cycles

Manage the Ports Build Cluster machines.
These machines continually build packages on all possible combinations of OS release and CPU architecture (in FreeBSD terminology, build environments.)

These builds also produce error logs for packages that do not build correctly (see the above URL). Periodically, the team marks these ports as BROKEN so that maintainers may be notified. (See below.)

Successfully built packages (at least, the ones that are freely redistributable) are also copied to the primary FTP server and thus become the default "latest package" for installations that use packages rather than ports.

Notify the FreeBSD community of problems within the Ports Collection so that problems do not get overlooked. To do this, there are a number of emailed reports. Ones marked public are posted to freebsd-ports.
- a public list of all ports to be removed due to security problems, build failures, or general obsolescence, unless they are fixed first.
- private email to all maintainers of the affected ports (including ports dependent on the above).
- private email to all maintainers of ports that are already marked BROKEN and/or FORBIDDEN.
- private email to maintainers who are not committers, who have PRs filed against their ports (to flag PRs that might never have been Cc:ed to them).
- public email about port commits that break building of INDEX.
- public email about port commits that send the revision metadata backwards
- private email to an affected port maintainer when a port is about to be marked BROKEN, Cc:ed to the last committer to the port. (This email is not automated but it should be sent as a courtesy.)
Remove expired ports. Ports that have been marked BROKEN for some time are marked DEPRECATED (with an EXPIRATION_DATE) and then are removed if no one has fixed them by that time. The intent of this process is to try to ensure that if a user installs a port, there is the best possible chance that it can be made to work.

In other cases, ports are marked DEPRECATED when they have been replaced by a newer version and the older version is no longer maintained by the authors. The EXPIRATION_DATE should generally be set at least two months in the future to allow everyone sufficient time to upgrade.

Last modified on: December 25, 2023 by Muhammad Moinur Rahman