This is my take on this:


>      I know NetBSD's philosophy is to only give out the best written, 
>      best operating things in it's system.  I think we need to change
>      that philosophy.

I strongly disagree with this.  One of the biggest reasons why 

Quantity != Quality, and, for certain purposes, Quality is definitely
better in the long term.


>      I'm not saying anyone has done anythng wrong, I just think that the
>      CORE teams job should be to incorporate things others have written, and
>      not spend so much time writting new things.  Fix bugs, incorporate
>      things people have written, and then work on things they think
>      should be fixed/redesigned.

The 'core' group does what a 'system architect' would do.  That
includes:
	(1) designing things,
	(2) setting directions of the code base,
	(3) possibly implementing things.

There are a _lot_ of people with access to the source tree who can't
or don't want to do (1) or (2), but want to fix bugs, maintain certain
programs, etc.  In general, they've been given source tree access
because:
	(1) they've asked for it, and
	(2) they've earned it (by maintaining packages independently,
		providing lots of bug fixes, etc.), and
	(3) they've demonstrated that they 'do things right.'

You'll notice that there're relatively few cases of "person did X,
it was then backed out by person Y because it was broken" (and most
of the instances of that you see are because it was only half done).


People are welcome to integrate as much software as they like into the
system, and then present it to 'core' or the responsible party for the
chunks of code that they're changing, to have it put in the master
source tree.  However, if there aren't people designing new parts of
the system (or redesigning existing parts), the entire system will
suffer for it.


If you see that the i386 port has fewer features than you think it
should, DO SOMETHING ABOUT IT.  you'll note that not all ports have
that problem; maintenance of a port is up to its maintainer.

There are a _lot_ of people and institutions using NetBSD, and many of
them based their decisions on the fact that the code _does_ have the
quality it has, or the fact that we support as many systems as we do.
That's what we've always set out to do, and I, for one, plan to keep
doing it.


As for why _I_, personally, spend so much time 'designing' things
rather than integrating i386 software:

You know, except for the i386 i use as a terminal (it's got 4M RAM and
only 100M disk, so it's not really useful as a development system),
i've not had an i386-family machine in my office or home for over a
year.

For the last year or so, i've _only_ had access to Alphas, and,
frankly, i like them a heck of a lot more than i've ever liked the
x86.  To start, they're faster...  8-)

A lot of the work that i do is directly in support of the Alpha port.
(You'll also note that for the last year, working on NetBSD/Alpha has
been my paying job, as well...  8-)  That means completely rewriting
monstrously broken code, all over the source tree.  Very little code
is written with the goal of multi-architecture compatibility in mind,
and even less can be shared between 32-bit and 64-bit architectures.
That's one of the things that i'm trying to fix in the NetBSD source
tree.

The 'redesign' work that i've done for the alpha port has (amazingly)
benefitted the i386 significantly.  Some of those benefits you've
seen, some of them i'm still working on...



My point is:

An operating system without good, designed interfaces isn't worth the
paper it's listed on, to researchers and develoepers, regardless of
the number of features it has.

If you want 'advanced' features incorporated into NetBSD, then:
	(1) integrate them yourself, and make them available for
		comment, etc., and use the feedback you get to improve
		them. 
	(2) support the developers.  As far as i know, i'm the _only_
		NetBSD developer who's ever been paid to work on a
		port of NetBSD, and i'm (and you're 8-) lucky that my
		boss lets me work on things that appear irrelevant
		to the port...  Very few of the developers have even
		received hardware to develop things on; it's
		impossible to test, develop, and maintain APM support,
		for instance, unless you have hardware that uses APM.


chris