Implementation Issues Involving the Ports Collection

Unlike the src tree, the FreeBSD ports tree is not branched. It has always been felt that there are too few volunteers to be able to handle the work of merging hundreds of changes from the latest tree into various branches.

There are thousands, if not tens of thousands, of user installations that track the ports tree on a daily basis, rather than relying on the packages that shipped with the most current FreeBSD release. Accordingly, any fatal error in the ports framework will immediately affect all of these sites. This is why commits to bsd.port.mk are only allowed with portmgr approval. Except in unusual cases, this approval is only granted after a regression test has been run on a dedicated area of the automated ports building cluster. Typically, a dozen or more proposed changes to the infrastructure are tested at the same time, and only after a build of the entire ports tree succeeds will portmgr commit the changes.

Changes to bsd.port.mk are not the only commits that can have a drastic effect on the tree. We request that any such changes also be tested on the cluster. Examples of such changes that should be tested before committing include:

If you are unsure of whether your proposed change will require a regression test, please send email to portmgr@FreeBSD.org.

When a new release of FreeBSD is upcoming, committers are asked to shift their emphasis away from introducing new ports and features and instead focus on fixing existing problems. At some time during the release, the tree is tagged and packages are created from each of the ports, for each of the architectures. Due to the large number of ports and the speed of the slower architectures, the build process takes several days.

In an ideal world, these would be the packages that went on the release CDs, and the time from the creation of the packages to the time of the actual release would be just long enough to test them and no longer. However, in practice, problems are found with both the ports and with the source tree as the QA effort continues. But to be able to release in a timely manner, only certain port changes will be merged back into the actual (tagged) tree, and the affected packages will be rebuilt. Only severe security problems and licensing issues will have their tags slipped in this manner.

Since the release period can take weeks, it is unrealistic not to allow any commit to the ports tree during this time. The problem with allowing unrestricted commits at that time is that it becomes impossible to separate out only the critical changes so that they, and only they, can have their affected tags slipped. The terminology for changes that are not allowed is sweeping changes.

A sweeping change is a commit that would affect a non-trivial number of packages in a way such that any other change (such as fixing a single security problem) would mean that we would have to rebuild the entire set of packages, which would delay the upcoming release, possibly by weeks, because the set of changes overlap.

Here is an incomplete list. If you are unsure that your proposed change falls into this categorization, you must ask portmgr before committing.

The following do not fall into the above category:

To summarize: the basic test is will this change affect other packages?.