From owner-svn-ports-all@FreeBSD.ORG Mon Mar 10 07:24:51 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 6B9B9115; Mon, 10 Mar 2014 07:24:51 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3FB26EF5; Mon, 10 Mar 2014 07:24:50 +0000 (UTC) Received: from [192.168.0.20] (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 04E7E438BE; Mon, 10 Mar 2014 02:24:32 -0500 (CDT) Message-ID: <531D68A0.3060701@marino.st> Date: Mon, 10 Mar 2014 08:24:16 +0100 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alexey Dokuchaev , Gerald Pfeifer Subject: Re: Deprecation policies References: <201403070625.s276PGbO062948@svn.freebsd.org> <20140307090840.GB98331@FreeBSD.org> <7A2A804C-B978-4259-9945-27A764EC9AB7@gmail.com> <20140307092408.GA3390@FreeBSD.org> <20140310065041.GB11693@FreeBSD.org> In-Reply-To: <20140310065041.GB11693@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, ports-committers@freebsd.org X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: marino@freebsd.org List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 07:24:51 -0000 On 3/10/2014 07:50, Alexey Dokuchaev wrote: > On Sat, Mar 08, 2014 at 01:09:50PM +0100, Gerald Pfeifer wrote: >> If anything, I think we need to consider becoming more aggressive: >> >> A port that fails to build on either of the latest two major release >> branches for X months gets deprecated. > > Fine by me, however, I'd added that whoever is deprecating it due to > build breakage should try to unbreak it first: sometimes this is very > easy to fix (like with net-p2p/microdc2). I think it's pretty clear that this staging effort doubles as housecleaning. A lot of cruft is getting exposed, and a lot of missing maintainers are getting discovered. Personally I have no issue with ports being on a very short lease. One port gets resurrected out of how many garbage candidates? And the end result is that it was fixed? I'm not seeing a problem, only good results. > >> A port that does not support staging by my birthday gets deprecated. > > Agreed; but it seems people are stagifying them as a pretty fast pace > already, so it is not really a problem. I take issue with this. If you were one that was doing all this extra staging I'd be fine with this statement, but last I looked you had over 60 of your own ports that need stage support. At this rate, somebody will have to do that work for you, so I really take issue that you are relying on this work by others for rate. I'm guilty too but at least all my own ports (~35) have been staged for a long time. I'm still not taking this volunteer effort for granted though. >> Any such ports that have been deprecated for two months and not seen >> any work to fix them get removed. > > I still don't see the reason to remove ports so promptly. I would say > half year looks more feasible to me; it also gives more time to build > clusters to recover from occasional sporadic, transient, or network > errors. Most of the ports getting culled have had WAY longer than 6 months to get right. Resurrection is the real way of knowing if anybody finds value in the port. Most will stay dead wthout anybody making a peep. All the ports are saved by SVN, I'm not seeing any sort of problem. John