From owner-freebsd-ports@FreeBSD.ORG Tue Apr 26 05:55:22 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1436106566C for ; Tue, 26 Apr 2011 05:55:22 +0000 (UTC) (envelope-from ade@FreeBSD.org) Received: from panix.lovett.com (panix.lovett.com [166.84.7.128]) by mx1.freebsd.org (Postfix) with ESMTP id C9AD18FC08 for ; Tue, 26 Apr 2011 05:55:22 +0000 (UTC) Received: from cpe-66-68-128-204.austin.res.rr.com ([66.68.128.204] helo=inferno.lab.lovett.com) by panix.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QEbF3-000606-Od; Tue, 26 Apr 2011 05:55:21 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ade Lovett In-Reply-To: <20110426024122.GA38579@comcast.net> Date: Tue, 26 Apr 2011 00:55:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB6165F.1010806@FreeBSD.org> <20110426024122.GA38579@comcast.net> To: Charlie Kester , FreeBSD Ports X-Mailer: Apple Mail (2.1084) Cc: Subject: Re: saving a few ports from death X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:55:23 -0000 On Apr 25, 2011, at 21:41 , Charlie Kester wrote: > Maybe freshports could implement a voting system like the one at > osx.iusethis.com? "Voting" implies some kind of democracy. This may come as a shock to folks, but FreeBSD in general is in fact not = democratic. It's based around the concept of folks putting in their own = time to keep a part of the Project alive. Whether it's a device driver, some chunk of base userland, = ports//, or support for an entire architecture and/or release = of FreeBSD -- doesn't matter. Without at least a modicum of active = maintainership (hint: MAINTAINER=3D ports@FreeBSD.org is _not_ active) = then it will eventually fall by the wayside and die. For ports, there's a non-zero cost associated with each and every single = one in the tree. Directly, in terms of clusters trying to build = packages for the combination of supported releases and architectures, = and indirectly, in case of infrastructural changes affecting chunks of = the tree, when it comes to determining whether port breakage is a result = of said changes, or whether it was broken already. Generally speaking, such "dead" ports are marked DEPRECATED with a = sizable amount of time before being reaped. Honestly, I'd personally = prefer the variable to be named PUT_UP_OR_SHUT_UP (but that's just me). = The fact remains though, that that is _exactly_ what it is. If, in the = period between a port being marked DEPRECATED and it being removed from = the tree, and especially in the case of UNMAINTANED=3DYES (that'd be = ports@FreeBSD.org for those in the back), no-one steps up to (a) fix the = problem, (b) take maintainership and (c) _continue_ with maintainership. Well, in that case, the port does not _deserve_ to live. After all, = no-one cares about it. If they did, they'd take care of (a) thru (c) = above. -aDe