The Ports Management team is pleased to announce that Thomas Abthorpe, tabthorpe@, has become a full voting member of the team. He will continue in his substantive postion as the -secretary in addition to other duties he will pick up along the way.
erwin@ committed http://www.freebsd.org/cgi/query-pr.cgi?pr=149657, based on work by dougb@ and rene@. It deprecates the use of md5 checksums in distinfo. So here on in, when you run make makesum, the md5 will no longer be generated, only the sha256 checksum.
Existing distinfo containing md5 info will silently be ignored. So at this time there is no need re-create distinfo for the sake of removing it, just allow the regular flow of ports updates take care of it.
The FreeBSD Ports Management Team wishes to remind users that November 30
is also the end of support for the Ports Collection for both FreeBSD 6.4
RELEASE and the FreeBSD 6.x STABLE branch. Neither the infrastructure nor
individual ports are guaranteed to work on these FreeBSD versions after
that date. A CVS tag will be created for users who cannot upgrade for some
reason, at which time these users are advised to stop tracking the latest
ports CVS repository and use the RELEASE_6_EOL tag instead.
While many people still use RELENG_6, it is at the end of it’s development
cycle. The Ports Management team has set the following policies with regard
to EOL/EOS of this branch and we kindly ask developers to implement these:
- We will keep building 6.4 packages as long as we have the resources.
6.x package builds will however be deprioritised, meaning they will not
be rebuilt as frequently.
- We will continue to support the 6.x infrastructure until RELENG_6
EOL (11/30/2010) by building the INDEX on RELENG_6 for use by ‘make
fetchindex’, and making sure that the ports collection infrastructure
(bsd.port.mk, etc) continues to function on RELENG_6, subject to the
reduced testing that this branch will receive. This means that problems
may be noticed only after the fact and may require community support to
develop and test fixes.
- We do not require committers/maintainers to support 6.x, but ports
will need to be marked BROKEN/IGNORE if they do not build/run.
- Port maintainers are strongly encouraged to accept patches from the
community that allow their ports to build and run on 6.x. However,
since running on 6.x is no longer a requirement, maintainers may use
their discretion in cases where a proposed patch would be disruptive
to other supported FreeBSD branches, or would unreasonably impede
ongoing maintenance of the port.
- We will continue to accept patches for ports collection infrastructure
- We encourage all users and developers to migrate to the FreeBSD 7.x or
8.x branch, both of which is a stable and mature platform, and are now
the ‘reference’ branches for the ports collection.
Please also see the secteam@ announcement,
In preparation for 8.1-RELEASE, the ports tree is now in feature freeze.
Normal upgrade, new ports, and changes that only affect other branches are allowed without prior approval but with the extra
Feature safe: yes tag in the commit message. Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependent ports, and any other commit that requires the rebuilding of many packages is not allowed without prior explicit approval from portmgr after that date.
When in doubt, please do not hesitate to contact portmgr.
Just in case you missed it on the mailing list, http://lists.freebsd.org/pipermail/freebsd-ports/2010-June/061882.html, the tentative date for Feature Freeze will be June 18, noonish UTC.
In preparation for 8.1-RELEASE, the ports tree will be in feature freeze after release candidate 1 (RC1) is released, currently planned for June 11.
If you have any commits with high impact planned, get them in the tree before then and if they require an experimental build, have a request for one in portmgr@ hands within the next few days.
Note that this again will be a feature freeze and not a full freeze. Normal upgrade, new ports, and changes that only affect other branches will be allowed without prior approval but with the extra Feature safe: yes tag in the commit message. Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependencies, and any other commit that requires the rebuilding of many packages will not be allowed without prior explicit approval from portmgr@ after that date.
During the month of May, we were fortunate enough to see the return of two old committers. Marc Fournier, aka scrappy@, well known for http://www.bsdstats.org, and Ade Lovett, aka ade@, aka Mr. Autotools.
Please feel free to drop them a note to say welcome back