From owner-svn-ports-head@freebsd.org Wed Aug 26 12:05:35 2015 Return-Path: Delivered-To: svn-ports-head@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 5E4A69C2A18; Wed, 26 Aug 2015 12:05:35 +0000 (UTC) (envelope-from freebsd.contact@marino.st) 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 79B45615; Wed, 26 Aug 2015 12:05:34 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.20] (178.Red-83-41-29.dynamicIP.rima-tde.net [83.41.29.178]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 3A05A43BD7; Wed, 26 Aug 2015 07:05:25 -0500 (CDT) Subject: Re: svn commit: r395079 - in head/graphics: . mitsuba mitsuba/files To: Alexey Dokuchaev , Baptiste Daroussin References: <201508230856.t7N8uwal009338@repo.freebsd.org> <96D957F8044D8B647B259802@atuin.in.mat.cc> <20150824070915.GA15244@FreeBSD.org> <20150824084807.GA93486@ivaldir.etoilebsd.net> <20150824090104.GB93486@ivaldir.etoilebsd.net> <20150824094539.GA77434@FreeBSD.org> <20150824102328.GC93486@ivaldir.etoilebsd.net> <20150826114234.GA78599@FreeBSD.org> Cc: Mathieu Arnold , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org From: John Marino X-Enigmail-Draft-Status: N1110 Reply-To: marino@freebsd.org Message-ID: <55DDAB81.2030302@marino.st> Date: Wed, 26 Aug 2015 14:05:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150826114234.GA78599@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 12:05:35 -0000 On 8/26/2015 1:42 PM, Alexey Dokuchaev wrote: > On Mon, Aug 24, 2015 at 10:53:48AM +0200, John Marino wrote: >> Not to mention that it's pointless to support earlier than officially >> supported platforms because everyone else is ripping out support every >> time they touch a port and see it, actively. In some cases, the only >> change in the commit is removing support. [EOL means EOL.] > > Yeah, I'm worried about this. I have nothing against removing actual > cruft -- e.g., BROKEN_FreeBSD_8 statements since they are not really > breaking anything, just making Makefiles cleaner and easier to maintain. > > Yet I believe it's better to discuss with maintainers when removing the > actual support. Maybe it looks different for those OSX-on-their-laptop > developers, but having all my gear FreeBSD based it usually always an > unfortunate moment to upgrade. > > People also might argue that breaking ports will urge dumb users like > myself to upgrade faster. While this has some merit, let's not forget > that EOLing the release will cause ports to break by themselves, and > forcing things does not really change much in the long run, but annoys > users a lot: no one likes them things are forcibly broken rather then > being let die teethless in their bed. > Somebody initiates this exact discussion literally every time a platform falls into EOL. The most obviously ones when the ports tree is changed a couple of days after EOL with the knowledge it will break support of the EOL platform, and then those users of said platform said that was too aggressive (e.g. they expect gradual bitrot, not full out breakage). Unfortunately they should expect full out breakage immediately and count every day that works beyond EOL as a bonus. IMO, any expectation of "slow-death bitrot" after EOL is unrealistic and maybe we would do people a better service of dispelling this notion rather than perpetuating it. FWIW I don't support removing EOL support actively (as the only change) but do think it should be removed when coupled with other maintenance and not just left because it still works in theory. John