(In)Stability of the Quarterly Branch

David Demelier demelier.david at gmail.com
Thu Dec 15 13:16:20 UTC 2016

2016-11-16 13:17 GMT+01:00 Vlad K. <vlad-fbsd at acheronmedia.com>:
> 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 problem is that there are no tests in FreeBSD ports. All source
based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo;
FreeBSD is the one that have the most instability. Not to mention
committers that commit without testing the port, just look at
www/redmine to get your point of view on that issue.

On the other hand, your idea is indeed good and could be a good start.
Quaterly branches change too quickly. That's simple: each time I
install a new port, I'm behind 2 or 3 quarters the last one. So I
usually update all before installing the new one.

What I want: a ports tree that matches the FreeBSD version like
OpenBSD. You have FreeBSD 11.0? You get a ports tree for that version
specifically. No major update, no breaking changes. Just bug fixes.
That will also simplify a lot FreeBSD ports by not having thousands of
conditional checking the FreeBSD version.

Waiting for more stability, I really encourage people to use poudriere
to build packages to avoid breaking a system at each upgrade.


Demelier David

More information about the freebsd-ports mailing list