From owner-cvs-all@FreeBSD.ORG Thu Sep 30 21:47:02 2010 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E63A1065674 for ; Thu, 30 Sep 2010 21:47:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A5C6B8FC39 for ; Thu, 30 Sep 2010 21:47:01 +0000 (UTC) Received: (qmail 31963 invoked by uid 399); 30 Sep 2010 21:47:00 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Sep 2010 21:47:00 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA50552.5050703@FreeBSD.org> Date: Thu, 30 Sep 2010 14:46:58 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Erwin Lansing References: <201009272151.o8RLpA8I002279@repoman.freebsd.org> <20100928024255.GA61304@FreeBSD.org> <20100928075649.c3bcb0a9.ehaupt@FreeBSD.org> <20100928122336.GB32589@FreeBSD.org> <4CA269E6.4030005@FreeBSD.org> <20100929070005.GU77643@droso.net> In-Reply-To: <20100929070005.GU77643@droso.net> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/sysutils/screenie Makefile pkg-descr X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 21:47:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 9/29/2010 12:00 AM, Erwin Lansing wrote: | On Tue, Sep 28, 2010 at 03:19:18PM -0700, Doug Barton wrote: |> That concern is understandable, but the problems come in down the road |> when something in the infrastructure changes, and there is no one to |> update the stale port. Not culling stale stuff is also how you get into |> situations like I cleaned up recently where you have ports that haven't |> even been fetchable for years still sitting around because no one pays |> attention to them. |> | This case is actually actively taken care of, ACK, but since the question came up, I think it's worth discussing in a little more detail. | although of course some | cases will fall through the cracks. Portmgr does occassionally run a | full build of all ports on the pointyhat cluster with local caching | turned off, forcing all ports to be fetch from the configured | MASTER_SITES. Right. The particular cases I was referring to were ports that required ack'ing a license in order to download, which is a case that (understandably) can't be handled programmatically. However that was just the latest bit of cruft that I personally have cleaned up (not that I'm trying to toot my own horn here). My larger point is that with the massive number of ports that we have I think there needs to be _less_ tolerance for unmaintained ports than we have had in the past because the larger the total number of ports gets the harder it is to keep things un-crufty. This is particularly true with ports that we don't anticipate software updates for since new versions of things tend to stimulate interest from potential new maintainers. | In fact, I started one just yesterday. Maintainers will | be informed and unmaintained ports will be marked BROKEN, and lateron | scheduled for deletion. But like you said, there will still be cases | that will fall through and we do need to get better at removing stale | ports. I'm glad to see that we at least agree on principle here. :) Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMpQVSAAoJEFzGhvEaGryEi1oH/jtRz2y3Ki+EpkeTzTaMTNdx QrUzlts4zgZ08yHBDe99Y+GCpJ5eu2MY22v8FGRzUBuQr6Km+vJD/3sSO1I9tutZ uViaub7CdHySpMC9f1mimLIeoOXQe6X5+/ltiXPkogviqhqNU/crOMIO+yADbvQ6 WmszE1WVsKCFLO1o885PNMvy08zsYY0milzHzclKzgBEbuzmS6iomF3DEG61vf72 97ID0QchwZmOH60ZAxdPS0b89BoGeLBiFWZZ3IV8XekkYTJ+KqpmXCmLDO2Mkcq0 XZ/B1CRNTiKB8BTG+CDZ6/sl2gemJ8oeiEVX7+EV6tbUyy0aOzCLqpXyq/IeTIU= =tC0g -----END PGP SIGNATURE-----