pkgsrc freeze guidelines

The primary goal of the pkgsrc freeze is to produce the
next stable branch of pkgsrc. Commits to the pkgsrc HEAD
during a freeze should be aimed at reducing the open
pkgsrc-related PR
count, and reducing the number of broken packages in the bulk
builds.

No infrastructure changes nor new packages should be
committed. This includes non-trivial changes to
buildlink3.mk files.

Package updates are only allowed for leaf packages
or for packages with security issues. For non-leaf packages
approval must be asked for and given (by pkgsrc-pmc) on the pkgsrc developers
mailing list.

Approval requests to the
pkgsrc developers
mailing list must answer the following questions:

Why is it critical to update this package for the
upcoming branch?

What changes should be expected between the current
version and the updated version?

Commits should only be made to fix portability issues,
build problems, or for addressing open PRs.

Commit messages should note explicitly why the commits
were made during the freeze period, and if necessary, who
gave the approval, e.g.:

“Updated during the freeze to fix security issue
noted at http://...; approved by ...”

“Updated during the freeze to fix problem noted
n pkg/NNNNN; approved by ...”

Importing or updating packages

Critical bug fixes, security updates, and build fixes can be
pulled up to the latest stable pkgsrc branch. Please forward
the “cvs commit” mail from the pkgsrc-changes
mailing list to the pullup address.

The pkgsrc pullup ticket tracking summaries are found by adding
“index-pkgsrc.html” to the
http://releng.NetBSD.org/ URL. (Not directly linked to avoid
automated e-mail spidering.)

We need to coordinate providing a good set of binary packages
for as many arch/osrev combinations as possible.

It is critical to ensure binary packages are built against the
same set of depends to avoid install conflicts. The most
practical way to arrange this is to use the bulk building system
and upload the complete set of packages after every build.

Developers interested in assisting (all are invited) should
subscribe to the <pkgsrc-bulk@NetBSD.org> list, and
check localsrc/admin/bulk-packages for an
available arch/osrev combination.

bulk-packages conventions:

When taking over an arch/osrev combination either start
bulk building from scratch, or download the current set of
binary packages from ftp.NetBSD.org to 'pre seed' the
build process (most useful for slower architectures).

When uploading packages upload/rsync the entire set
of bulk built packages, and delete any other packages for that
arch/osrev from ftp.NetBSD.org.

If no longer able to handle a build, remove the entry
from localsrc/admin/bulk-packages and
notify pkgsrc-bulk.

Any developer can upload updated/new/security-fix
packages to ftp.NetBSD.org, but they
must be built against the set of binary
packages already present for that arch/osrev.

Machines should run the latest minor release,
or (recommended) track the release branch.

Note

This does not address the issue of new versions of
binary packages not installing against a user's existing
set of installed depends, or a updated depend potentially
requiring an update of many other packages already installed
in their machine.

Current options for that would be either freezing binary
packages at tagged values, or having multiple binary package
trees per arch/osrev. The former significantly reduces the
utility of the binary packages, and the latter is not worth
considering until we can get one
consistent tree per arch/osrev.