From owner-svn-ports-all@FreeBSD.ORG Thu Jul 31 08:37:48 2014 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB64492E; Thu, 31 Jul 2014 08:37:48 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 809372A64; Thu, 31 Jul 2014 08:37:48 +0000 (UTC) Received: from [192.168.0.21] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id BF01043BA8; Thu, 31 Jul 2014 03:37:28 -0500 (CDT) Message-ID: <53DA0037.1060809@marino.st> Date: Thu, 31 Jul 2014 10:37:11 +0200 From: John Marino Reply-To: marino@freebsd.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alexey Dokuchaev , marino@freebsd.org Subject: Re: svn commit: r363524 - in head/emulators/pearpc: . files References: <201407302302.s6UN2GCn094189@svn.freebsd.org> <20140731060809.GA20983@FreeBSD.org> <53D9E30D.3030902@marino.st> <20140731065333.GA39915@FreeBSD.org> In-Reply-To: <20140731065333.GA39915@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Roman Bogorodskiy , ports-committers@freebsd.org X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 08:37:48 -0000 On 7/31/2014 08:53, Alexey Dokuchaev wrote: > > This is actually one of my concerns over bulk version updates with simple > build testing, lacking required run-time testing (even better, for some > longer period like days). Well, sure, everyone would agree that thorough run-time testing would be ideal but it's simply unrealistic due to: 1) The time required 2) more important, the expertise required. The vast majority of the 25K ports in the tree, I've never used. I have no idea how to do basic runtime testing on them much less a thorough review (All I could give is to see if it starts up) In this case, to run-test this is even more obnoxious, you need to download an image from apple, presumably a large image. I have a 20G data limit *per month* (unlimited at night) because I have satellite-based internet. I can't afford data use like this. And --- we have have a huge backlog on the PRs. the time is better spent getting through PRs 3, 6 even 12 months old rather than burning it all on one 10-year unmaintained port. Let's use what limited volunteer time we have wisely, and let users submit new PRs if there's a run issue (which indicates the port is actually used as well). John