From owner-freebsd-ports@freebsd.org Thu Dec 15 16:35:57 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E98DBC813F8 for ; Thu, 15 Dec 2016 16:35:57 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id D70861158 for ; Thu, 15 Dec 2016 16:35:57 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from C02LJ0HMFFT4.corp.proofpoint.com (static-58-108-170-168.optusnet.com.au [58.108.170.168]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0OI800K44JT96M20@hades.sorbs.net> for freebsd-ports@freebsd.org; Thu, 15 Dec 2016 08:43:58 -0800 (PST) Subject: Re: (In)Stability of the Quarterly Branch To: "Vlad K." , Freebsd Ports References: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> From: Michelle Sullivan Message-id: <5852C669.4040409@sorbs.net> Date: Fri, 16 Dec 2016 02:35:53 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 In-reply-to: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:35:58 -0000 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