From owner-freebsd-ports@freebsd.org Mon Dec 12 16:15:32 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 0571BC731A2 for ; Mon, 12 Dec 2016 16:15:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C5C6C15E9 for ; Mon, 12 Dec 2016 16:15:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uBCGFLXG022401 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 12 Dec 2016 08:15:25 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: The ports collection has some serious issues To: "Vlad K." , freebsd-ports@freebsd.org References: <29bc829f5bdbf18a38218b23ddf3afea@acheronmedia.com> From: Julian Elischer Message-ID: <1e49f0bd-f9e8-8698-0ba7-e9964a9f8c67@freebsd.org> Date: Tue, 13 Dec 2016 00:15:16 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <29bc829f5bdbf18a38218b23ddf3afea@acheronmedia.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: Mon, 12 Dec 2016 16:15:32 -0000 On 8/12/2016 6:05 PM, Vlad K. wrote: > On 2016-12-08 06:16, Daniil Berendeev wrote: > > > I mean, they are the FIRST landing point of a change. And the only > QA we ask for that change is a confirmation that poudriere and > portlint have been run, the rest is at liberty of committers how far > they'll go with own testing before they commit. For many, only > builds against -CURRENT or latest -RELEASE are done because it's > very time consuming to test against all supported FreeBSD versions, > and not just versions but various permutations like different > pythons etc... When it comes to some defaults like OpenSSL (or any > kind of dependency on it), all of those tests are required. > > The problem is, FreeBSD doesn't have a STABLE repo that would > receive gradual updates from HEAD as they prove themselves stable. > QUARTERLY != STABLE, it's just a snapshot of whatever state HEAD is > in, with a loose promise the ports in it will receive "security and > bugfixes only" but that's a separate set of issues. The problem I get hit by is that the quarterly packages are deleted immediately on the creation of the next quarterly set. so by definition, when you've spent 3 months getting the quarterly pkg collection reliable and correct, it gets deleted. I think there should be two quarterly pkg collections available at any time: The one we are stabilising, and the previous stable set (called beta and stable or something like that). the stable one is basically read-only except for security fixes. As it is when you get the new quarterly packages, they are straight off head, because the branch was just made. > > There are some solutions and we don't have to NIH or reinvent the > wheel. Just looking at what other open source projects do with, say, > GitHub and continuous integration testing, every pull request gets > an automated test. Why don't we do that? Is it difficult to > implement it? > > I am also convinced that such testing can be automated and a true > "STABLE" repo can be made instead of manual QUARTERLY that breaks > promises. I think this is heading in the right direction.. at the end of the 3 month stabilisation it goes to stable. > >> 8) ports with vulnerabilities. >> They exist in the tree and on build attempt they shout that they won't >> build without DISABLE_VULNERABILITIES=yes. The catch is that there is >> always a bunch of ports with vulnerabilities. So if you are doing a > > That's just a nature of it, and the consequence of VuXML being a > separate port that gets often updated first, as it's better to > announce the vuln before it was fixed. And fixing is bound to > maintainer timeouts, poor issue tracking via Bugzilla, etc... > > > >> I hope that my mail will produce a productive discussion that will >> lead >> to some good decisions for fixing these problems. > > Probably not. I've already posted about issues with head/quarterly, > hoping for a discussion, never happened. Others have complained > about the same problem, but no constructive discussion ensued. Is my > frustration coming through, yet? :) yeah it's not working well at the moment. The procedures could do with some tuning for sure. > > > > >