From owner-cvs-ports@FreeBSD.ORG Sun Feb 6 02:26:30 2011 Return-Path: Delivered-To: cvs-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B74C41065673 for ; Sun, 6 Feb 2011 02:26:30 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 699B48FC0C for ; Sun, 6 Feb 2011 02:26:29 +0000 (UTC) Received: (qmail 68370 invoked from network); 6 Feb 2011 02:26:28 -0000 Received: from 195.135.221.2 (HELO d95.suse.de) (195.135.221.2) by relay02.pair.com with SMTP; 6 Feb 2011 02:26:28 -0000 X-pair-Authenticated: 195.135.221.2 Date: Sun, 6 Feb 2011 03:26:32 +0100 (CET) From: Gerald Pfeifer To: Mark Linimon In-Reply-To: <20110128212637.GB4687@lonesome.com> Message-ID: References: <201101152257.p0FMvSTR058827@repoman.freebsd.org> <20110128212637.GB4687@lonesome.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: cvs-ports@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/graphics/metapixel Makefile distinfo X-BeenThere: cvs-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 02:26:30 -0000 On Fri, 28 Jan 2011, Mark Linimon wrote: >> Sometimes this is really frustrating. Way too many ports are just >> so, fragile, and the onus to fix up any the breakage then lies with >> those of us who care about general improvements and infrastructure. > (I should have responded to this earlier, sorry) No worries, we are all just volunteers! > I sympathize with your frustration. OTOH the only way we make progress > is if people like yourself pick up the totally-non-glamorous "dirty > work" and just grind through to get it committed. My point really is that the FreeBSD Ports Collection is hobbled by our current set of processes which does not scale to the extent FreeBSD needs, both in terms of the sheer number of ports and looking at how fast others are moving. Sure, we can have someone spend what turned out to be a surprising amount of time caring about unmaintained ports or having to wrestle with ports he is not familiar with only to get a small, and even obviously correct, change in. And there are volunteers like you who engage in mini-projects like this again and again. However, I am sure we are loosing lots of volunteers, energy and overdue changes like finally adding -I${LOCALBASE}/include to CFLAGS over these policies, making FreeBSD harder to use as a ports developer, more error prone as a user, and falling behind in innovation. Wouldn't you want to do higher value work that really makes a difference, and wouldn't that be better for the project overall? Again, here is my original proposal which I have seen no disagreement on, but also no indiciation this is something you guys are seriously considering: 1 An infrastructure change is submitted. 2. portmgr (or other maintainers) review. 3. If the review is positive, a pointyhat run is kicked off and for every new failure - if the port is maintained, a PR is opened and assigned to the port maintainer; - if the port is unmaintained, it is marked BROKEN and DEPRECATED with a deprecation period of two months. 4. Unless testing has uncovered a real issue with the infrastructure change, it is committed after two months at the latest. Gerald