HEADS UP: freetype2 upgrade

[Doug Barton]

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 at 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