From owner-freebsd-ports@freebsd.org Wed Nov 16 12:17:17 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 7F9A6C43B9A for ; Wed, 16 Nov 2016 12:17:17 +0000 (UTC) (envelope-from vlad-fbsd@acheronmedia.com) Received: from mail.irealone.com (fawn.irealone.com [IPv6:2001:1af8:4010:a07b:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C2A11F4B for ; Wed, 16 Nov 2016 12:17:17 +0000 (UTC) (envelope-from vlad-fbsd@acheronmedia.com) Received: by mail.irealone.com (Postfix, from userid 1002) id 93DD460F21; Wed, 16 Nov 2016 13:17:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=acheronmedia.com; s=mail; t=1479298634; bh=uKphKARtDQWakahBgopwHo7H+xJYpzMgImZKrHkRgDw=; h=To:Subject:Date:From:From; b=lo1tGYWUn65+p4YFNdg4KD4QgVb0iHvDmMkF8nUnyEHCV2+ovilSumdUd8moivnUL 6VPvqzP5/gRULBn4axxvs4mdyfSIkn8WLVgBuwuMJvPlQnhC3BIxyNWbFqwtH7/hT+ w68MOPw1+v3Mof5t44+XDhL6k46WBbF67EEytPhs= To: Freebsd Ports Subject: (In)Stability of the Quarterly Branch X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 Nov 2016 13:17:14 +0100 From: "Vlad K." Organization: Acheron Media Message-ID: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> X-Sender: vlad-fbsd@acheronmedia.com User-Agent: Roundcube Webmail/1.1.6 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: Wed, 16 Nov 2016 12:17:17 -0000 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? -- Vlad K.