From owner-freebsd-ports@FreeBSD.ORG Sat Apr 3 17:10:45 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D78816A4CE for ; Sat, 3 Apr 2004 17:10:45 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2AFD43D3F for ; Sat, 3 Apr 2004 17:10:44 -0800 (PST) (envelope-from DougB@freebsd.org) Received: from freebsd.org (c-24-130-160-161.we.client2.attbi.com[24.130.160.161]) by comcast.net (sccrmhc11) with ESMTP id <2004040401104301100c5ugre> (Authid: domain_name_tsar); Sun, 4 Apr 2004 01:10:43 +0000 Message-ID: <406F6092.9060901@FreeBSD.org> Date: Sat, 03 Apr 2004 17:10:42 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Linimon References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "freebsd-ports@freebsd.org" Subject: Re: HEADS UP: freetype2 upgrade X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 01:10:45 -0000 Mark Linimon wrote: > On Sat, 27 Mar 2004, Doug Barton wrote: > >>I think you (pl.) need to get your heads around the fact that we have >>several hundred ports [maintainers], many of whom have styles and ideas >>that differ from those of the "ports intelligentsia" that seems to have >>arisen over the last few years. And seriously, that needs to be ok. > > > How, then, do we address the problem of new port submitters and/or > maintainers, who, when they are confronted with the multiple existing > approaches in the tree, are frustrated when they can't figure out which > one they ought to use, i.e., which one is "better"? Wow. I am deeply saddened by this question (seriously). There certainly should be "A" way to get things done that is well documented in the porter's handbook, and in certain rare situations enforced because it is the "best" way. However, the fact that there is more than one way to do it is a strength of unix in general, and should not be considered something to work around or "fix" because someone might get frustrated. Investigating multiple options is one of the things that leads to creative thinking. THAT is certainly not something that we should be discouraging. > There is also the issue that some of the ideas have limitations, i.e., > there is more "method to the madness" than first appears. This is > especially true in that some of these ideas don't take into account > things like the desire to be able to install ports from a read-only > file system. I'm with you up to this point, and I agree that if something doesn't actually work, it should be replaced. However ... > The Right Thing in this case is not really a matter for > experimentation, there's pretty much one way that works and that's > it. ... this is just plain stupid. How do you think we got to where we are now if it wasn't by experimentation? Sometimes they work great, sometimes they just fall flat on their face and we start over again. But to say that there is only "one true way" is just ludicrous. > As you yourself have pointed out, it's hard to bring new ports > committers up to speed, and part of it is due to these subtleties. > Having the N different approaches only complicates this problem IMHO. Um, no. The kinds of things that I have been complaining about recently, like committers who don't test new tarballs of the same version of the software; are not "subtleties," they are "basics," and not areas where creativity is desired. >>one thing I *have* seen more of lately is ports maintainers giving >>up on the rat race of trying to keep up with a ports infrastructure >>that's constantly changing out from under them. > > > The infrastructure that worked for 1500 ports is not necessarily the > infrastructure that's going to work for 10500 ports. I made pretty much that same point in the part of my post that you snipped. > The refactoring > of a great deal of common code into USE_*, WANT_*, and WITH_* is a > prime example of this. And these things are great, as long as they are offered as a service to port authors (not a requirement), and don't break existing ports. >>If they're not careful, our all too clever ports gurus are going to >>find themselves sitting all alone on an island, wondering why so >>many ports say "MAINTAINER= ports@freebsd.org." > > > Number of ports with no maintainer: 2877 (27.0%) as of a few minutes > ago. You're not taking into account ports that are "dead in the water" that the maintainers haven't released yet. However, that 27% number alone is pretty disturbing to me. In any case, my main point is simply that it is highly contrary to the interests of the project for us to stifle creativity. Rather than trying to beat creative thinking out of people in the interests of making it easy for people not to have to think very much, we should be encouraging creative thinking, and channeling that creativity into new and better solutions that will help the ports tree to grow to 150,000 ports. Doug -- This .signature sanitized for your protection