From owner-cvs-ports@FreeBSD.ORG Sun Jan 16 02:57:59 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 69C2C106564A for ; Sun, 16 Jan 2011 02:57:59 +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 06F558FC08 for ; Sun, 16 Jan 2011 02:57:58 +0000 (UTC) Received: (qmail 88454 invoked from network); 16 Jan 2011 02:31:17 -0000 Received: from 195.135.221.2 (HELO g159.suse.de) (195.135.221.2) by relay02.pair.com with SMTP; 16 Jan 2011 02:31:17 -0000 X-pair-Authenticated: 195.135.221.2 Date: Sun, 16 Jan 2011 03:30:59 +0100 (CET) From: Gerald Pfeifer To: ports-committers@FreeBSD.org, cvs-ports@FreeBSD.org In-Reply-To: <201101152257.p0FMvSTR058827@repoman.freebsd.org> Message-ID: References: <201101152257.p0FMvSTR058827@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: 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, 16 Jan 2011 02:57:59 -0000 On Sat, 15 Jan 2011, Gerald Pfeifer wrote: > Modified files: > graphics/metapixel Makefile distinfo > Log: > Properly set CPPFLAGS and LDFLAGS at a Makefile level instead of just > within MAKE_ENV and incrementally instead of absolutely. 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. So far PR 153625, a really trivial and obviously correct change, has cost me some eight hours, and I shudder at the thought of how expensive finally passing LDFLAGS to CONFIGURE_ENV and MAKE_ENV will prove, let alone properly defaulting CFLAGS or LDFLAGS. Note, I am very grateful to those of you that incredibly quickly fixed their ports last week. I am truely impressed! Still I think we need a different and more scalable process, something like this: 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. Gerald