(In)Stability of the Quarterly Branch

[Michelle Sullivan]

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 
> 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?
>
>
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.

Michelle