Date: Sun, 6 Feb 2011 03:26:32 +0100 (CET) From: Gerald Pfeifer <gerald@pfeifer.com> To: Mark Linimon <linimon@lonesome.com> Cc: cvs-ports@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/graphics/metapixel Makefile distinfo Message-ID: <alpine.LNX.2.00.1102022359120.14698@gerinyyl.fvgr> In-Reply-To: <20110128212637.GB4687@lonesome.com> References: <201101152257.p0FMvSTR058827@repoman.freebsd.org> <alpine.LNX.2.00.1101152358150.2354@gerinyyl.fvgr> <20110128212637.GB4687@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1102022359120.14698>