From owner-freebsd-ports@freebsd.org Thu Apr 20 08:27:38 2017 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 16348D459B4 for ; Thu, 20 Apr 2017 08:27:38 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C21571B4E for ; Thu, 20 Apr 2017 08:27:37 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from ultrabook.yoonka.com (x52716370.dyn.telefonica.de [82.113.99.112]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id v3K8RRE8083316 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 20 Apr 2017 08:27:28 GMT (envelope-from list1@gjunka.com) X-Authentication-Warning: msa1.earth.yoonka.com: Host x52716370.dyn.telefonica.de [82.113.99.112] claimed to be ultrabook.yoonka.com Subject: Re: Is pkg quarterly really needed? To: freebsd-ports@freebsd.org References: <58F61A8D.1030309@a1poweruser.com> <29e44642-e301-f07c-afe3-bad735d8ee5e@freebsd.org> <20170420053722.GD31559@lonesome.com> From: Grzegorz Junka Message-ID: Date: Thu, 20 Apr 2017 08:27:20 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170420053722.GD31559@lonesome.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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, 20 Apr 2017 08:27:38 -0000 On 20/04/2017 05:37, Mark Linimon wrote: > I understand that having the quarterlies is not meeting your use case. > You've said that. We get it. > > So you want some kind of running -quarterly branch. > > But where are the N hours of work per week to QA all the patches to > the -quarterly branch, or a -stable branch, or whatever people seem > to demand, to come from? > > This is a serious -- if very irritated -- request. > > We've moved from a "we don't have enough person-power to manage a ports > branch" to "we kinda have enough person-power to manage both head and a > kinda-branch." OK. That isn't meeting all the use cases. Understood. > (...) > > Honestly without some volunteers to do the _hard_, _unrewarding_, work > to QA the ports tree, this is all either a) just talk, or b) people > wanting volunteers to provide professional-level support, for free. > > tl;dr: provide some resources, or don't. I am getting to the point where > I don't care either way. All I see is the people who are doing actual work > get poked in the eye. > I am not sure if this is a rant in favour or against quarterly branches. And this discussion comes up again and again quite regularly. I wonder why ports don't follow the development model of the FreeBSD kernel? In short: 1. CURRENT - latest upgrades from upstreams, a broken port or a port that breaks other ports shouldn't be committed but not all option combinations are fully tested. Don't rebuild all ports, at least not often (maybe once a month), but rebuild all dependant ports of a port whenever a change in that port has been made. 2. STABLE - Only upgrade ports to the version from CURRENT when users haven't reported any issues with any combination of options for that port for some agreeable period of time since the upgrade in CURRENT (e.g. 2 weeks, a month). Rebuild all ports more often than in CURRENT (e.g. fortnight) but also not too often. Like in CURRENT rebuild all dependant ports whenever a port on which they depend has changed. 3. RELEASE (optional) - Like STABLE - only upgrade ports to the version from STABLE if no issues with any combination of options has been reported for some agreeable period of time since the upgrade in STABLE (e.g. 2-3 months this time). Rebuild all ports more often than in STABLE (e.g. once a week). Also like in STABLE rebuild all dependant ports when a port on which they depend changes. Each branch would keep X latest full rebuilds (one, two, three - depending on resource availability) and the partial rebuilds in between them when dependant ports are rebuild - I think poudriere would copy them to the latest directory with packages by default. This could give something folders like: CURRENT month 1 any partial rebuilds on top of month 1 CURRENT month 2 any partial rebuilds on top of month 2 ... STABLE week 1 any partial rebuilds on top of week 1 STABLE week 3 any partial rebuild on top of week 3 RELEASE week 1 any partial rebuilds on top of week 1 RELEASE week 2 any partial rebuilds on top of week 2 RELEASE week 3 any partial rebuilds on top of week 3 etc. Then it would be a matter of creating a scheme for url addresses for easy access to these folders with build packages. Grzegorz