From owner-freebsd-ports@freebsd.org Thu Dec 15 13:16:20 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 060B0C81B65 for ; Thu, 15 Dec 2016 13:16:20 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B415E893 for ; Thu, 15 Dec 2016 13:16:19 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: by mail-ua0-x234.google.com with SMTP id 12so6683770uas.2 for ; Thu, 15 Dec 2016 05:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gBWZbVUf25oEdR/Bjxjd6Ps13zv1IiPs4MmjdDPA6yc=; b=iQdkXsQVzAcaa7cxz/IbpiGdtavBoCP/OHF/n9SaVMS+A9dxsB4V6ywJ2Bghwh+SNR bLTVybD8Dn4nKwgTflGbepeC2RTszf3mBiC3WzS2L10S0yEg6S5QuNwHSez2XmyONT3Y CjSB5c5YfMfEk+92SlUpTyfB0HDj4g8dPKGUZUOAfvf167db9ef9I8UyT7FnEfN7bFHw epJNIi4fXVWWd6KpmqvH3KUL9asd3f9bQg/qkQ1ivMlQrQKqyvcGiPvpz0QkmgO6wQkF VwApXHNBtrdZL2IPTrNPzDBHJxEBmAZ4L/qGEOtRSbF+7VpuSCDcJ/JRn44PWkdiRdgW SwgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gBWZbVUf25oEdR/Bjxjd6Ps13zv1IiPs4MmjdDPA6yc=; b=oBlk/fahO0S79Z8nNRRLio3Vl5SNQAH6wB/7x90JMym5U1xIwbWtw2r0xviK51YMqW dv6Aj3c8dqIG6B80vu1B8nvbLOKbkcS7Au9juX8INTxKMCPV4krq49ffLFCgCmL5vByl Yqk7I39GW8s1KPSjphzBNzo/gZ6x6GXhxVQcJRHigm5EjpaX1s1WFwaAhvoc4baG46Cn t0jAKTsDk4NPqATukMqWwShfDCae9UJOvlahxO2d0n+bIUhsrObq7npmx+U5+6ui6k1T TsjdUHp2sISXgAIXh4bORVssbxJXqBC/Mn13famNqaGBc71LekZn4yoOjwFp+s1Vxz2s whKA== X-Gm-Message-State: AKaTC007OHJ/MKt1Dv48AkAUv/QiPzkSVy9Rsw71rzAVBnjhNk2q2GiPP0Q6gnYtK2pDY5n0Gzf2t8dG6AuYdA== X-Received: by 10.176.2.247 with SMTP id 110mr976514uah.162.1481807778676; Thu, 15 Dec 2016 05:16:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.47.83 with HTTP; Thu, 15 Dec 2016 05:16:18 -0800 (PST) In-Reply-To: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> References: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> From: David Demelier Date: Thu, 15 Dec 2016 14:16:18 +0100 Message-ID: Subject: Re: (In)Stability of the Quarterly Branch To: "Vlad K." Cc: Freebsd Ports Content-Type: text/plain; charset=UTF-8 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 13:16:20 -0000 2016-11-16 13:17 GMT+01:00 Vlad K. : > 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. Regards, -- Demelier David