(In)Stability of the Quarterly Branch
michelle at sorbs.net
Thu Dec 15 16:35:58 UTC 2016
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.
> 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
> 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?
That's what it needed but people charging through new versions and
linuxifying FreeBSD screwed the pooch... This conversation/thread should
have happened 2 years back.
More information about the freebsd-ports