Date: Fri, 16 Dec 2016 02:35:53 +1000 From: Michelle Sullivan <michelle@sorbs.net> To: "Vlad K." <vlad-fbsd@acheronmedia.com>, Freebsd Ports <freebsd-ports@freebsd.org> Subject: Re: (In)Stability of the Quarterly Branch Message-ID: <5852C669.4040409@sorbs.net> In-Reply-To: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> References: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5852C669.4040409>