Please add my voice to this..
It's not really that much that needs to be done.
lets just call it 'learning from experience'
Also, the quarterly PACKAGES should be kept around a bit longer too.
and the pkg archives need to be in a layout that the system installer
can be pointed at them in 4 years time when you want to rebuild a
legacy machine.
On 16/11/2016 8:17 PM, Vlad K. wrote:
The quarterly branch (Q) is intended to provide a set of "stable"
packages that in the lifetime of such a branch, receive only bug and
security fixes. That is the theory and intent behind the branch. In
practice, however:
1. The Q branch is cut off at predetermined dates (ie. not when it's
stable and ready), and it is cut off from HEAD, thus including the
state of ports at that moment. This breaks the promise of stability
and guarantees that every 3 months there will be uncertainty as to
whether the fresh new versions are working or not. There is no such
thing as a "Pre-Quarterly repo" which would receive all updates for
the NEXT Q branch-off, and which would freeze and stabilize for some
time before branch-off. And even if it did, 3 months would be too
short.
It is effectively not much different from tracking HEAD and doing
updates only every three months, with the added benefit that SOME
security updates will come down sooner. But:
2. Unfortunately not all "security or bug-only fixes" are MFH'd, and
as a bugzilla triager I've had the opportunity to observe this in
practice. It can be as simple as accepting a minor upstream version
bump, or as complex as requiring cherry-picking and backporting code
if upstream mixes security, bug fixes with new features. It is
none-the-less a manual work requiring ports-secteam to review and
accept the patches. It is not clear who is supposed to do
cherry-picked backporting if the patches to HEAD cannot be MFH'd as
they are. It is also additional burden to the ports-secTEAM which at
the moment is, effectively, one person.
In out current build environment at $JOB we check out every package we
need in ports at it's own SVN revision.
Usually that is defined to be a default, but sometimes in order to get
a fully working set we need to slide a port or two forwards or
backwards a bit. (and hope it doesn't hit a ports API change). (this
means we really need to stay on head though)
As it is obvious that the promise of a stable repo in its current
form requires manpower and manual work which we do not have, my
proposal is to abandon the promise of "security/bugfix" only changes
and adopt the approach not unlike Gentoo's, in which a "STABLE"
repository receives ALL the updates from HEAD, but only after
certain criteria has been met, like minimal age of changes, no open
issues, a certain battery of regression/integration/unit tests is
performed, etc...
The key, I believe, is in automation which we can achieve with this,
and with that offer at least SOME level of stability without broken
promises. The key to this automation is no manual review, which can
only be achieved if we accept ALL changes, but stabilized to certain
degree.
The idea of a "stable" repository is a valiant one, we definitely
need it if we want to increase the usage of FreeBSD in production as
more than just a base OS that does routing and ZFS storage -- namely
production use of stable ports. And IMHO we only need to balance
between how stable we can provide/guarantee it and what resources
and manpower we have available to do so.
What are the community's thoughts on this?
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
