by homeworld.redbacknetworks.com with SMTP; 17 Dec 1998 14:53:52 -0000
	id 13D55148; Thu, 17 Dec 1998 09:53:15 -0500 (EST)
Approved: eat-raw-chocolate
  by homeworld.redbacknetworks.com with SMTP; 17 Dec 1998 11:17:09 -0000
	by shell17.ba.best.com (8.9.0/8.9.0/best.sh) id DAA23576;
	Thu, 17 Dec 1998 03:15:56 -0800 (PST)
From: Todd Whitesel <toddpw@best.com>
Message-Id: <199812171115.DAA23576@shell17.ba.best.com>
Subject: Re: Sun jumping on Linux bandwagon
In-Reply-To: <19981216084649.H10788@acheron.middleboro.ma.us> from Mason Loring Bliss at "Dec 16, 98 08:46:49 am"
To: mason@acheron.middleboro.ma.us (Mason Loring Bliss)
Date: Thu, 17 Dec 1998 03:15:56 -0800 (PST)
Cc: netbsd-advocacy@netbsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> Sorry if this seems like anti-advocacy, but I've been disappointed with
> several things related to the NetBSD project lately, and I've invested
> enough time and feeling into NetBSD that I feel let down. I'd like to see
> NetBSD thrive, but it ain't happening now, and I don't see any trends that
> indicate that it will happen in the future. Our Core team is dwindling, and
> the rest of us are doing nothing to promote NetBSD. There *are* people who
> are trying to improve things, but I can't see how *anyone* is going to be
> able to break through the ennui and inertia gripping the project.

I felt this way for much of this year; while it may not really be true, it
certainly seems that way from the outside.

Everyone I talk to at work who knows anything about free unix and actually
recognizes "NetBSD" generally has a blase' attitude towards it, and repeats
some line about how either (a) core are assholes, or (b) they're so quiet are
they dead or just in a coma.

I think a lot of the perceived ennui comes from some very obvious signs that
certain "simple" things just aren't getting done (my opinions only BTW):

    1. It seems like a lot of newbie contributed PR's die in committee. This
    turns people off, they switch away from NetBSD and give bad word-of-mouth.
    While the reasons for this are often complex and usually justified, really
    people should be able to expect _a_ response of some kind even if it is to
    say "we don't know, and no one has made time to investigate yet; thanks".

    2. Outside developers don't care about helping to debug compile errors in
    -current. They would be much happier if we could provide regular non-DOA
    snapshots, so that when they have a free week, they sync up, hack away,
    and then maybe publish their changes for review. I think a lot of grief
    would be eliminated if we had a fairly regular schedule for new snapshots
    and space on whichever FTP servers to keep a few lying around at any time.

    3. The projects page on the web site doesn't appear to get updated much.
    Something I have discovered at work is that when people can check a page
    full of status information which is updated daily, the sight of things
    slowly making progress encourages related development because there is
    much less uncertainty as to whether or not something is ready to be
    played with. When somebody is supposedly off working on something, the
    silence grows more and more ominous sounding as time goes on.

Okay, now obviously I wouldn't have posted all this if I weren't volunteering
to do something about it. :)

    1. I don't know anything about gnats, but I am willing to learn if it
    means helping to see that all new PR's eventually get sent at least one
    response at some finite rate (even one PR per week is okay at first, as
    long as people see _some_ progress!!). I am certainly not the best person
    to judge most of the PR's, but I can sure as hell send a form email to
    people in a few minutes every few days, and search the database for old
    PR's to see if something can now be done about them. I think this is
    currently done for the PR's that can be solved easily, but for the hard
    ones we appear to drop the ball from the outsider's perspective and I'd
    like to find a way to prevent that.

    2. "snapshot farm." I now have the ability to produce unofficial snapshots
    for i386, and (almost) arm32. When a tree is in good shape, my stuff DTRT,
    and when it is not, things cleanly fail so I can investigate and continue.
    Once things are humming I don't spend much time on it at all; I start a
    new kernel build in the morning while I shower, reboot over breakfast, and
    make build+distrib+tars while I'm at work. Before I can call something a
    snapshot, I think it should complete the above cycle at least three times,
    which in the process performs a 3-stage "grandfather test" of the compiler.
    I've decided to buy a $99 DEC Multia (NetBSD/Alpha) and run it headless,
    to see if this model works for Alpha as well. I will arrange for FTP space
    as necessary, since I don't want to confuse anyone looking for official
    snapshots on ftp.netbsd.org. Eventually www.toddpw.org will stop giving
    404's and I'll have links to all the completed snapshots there, and a page
    containing the generation system, HowTo's, etc.

    3. Here I think that just having someone massage source-changes into a
    daily digest would be a good start. I can do this too but I'd need to
    bone up on HTML again. Also I would like to have a version of this page
    for public projects that are happening outside of the tree. It seems to
    me that just having an email aliases "netbsd-progress@netbsd.org" would be
    great, so one does not have to troll _all_ the mailing lists to collect
    this stuff. Plus the pages should sort their info by date, so inactive
    projects go to the bottom and projects can fight for exposure in the top
    10 spots or something :)

Please bear in mind that I am about to squeeze out an arm32 snapshot and
then start cranking on an i387 emulator over the holidays; don't expect the
web stuff to happen for a bit. I'll put prototypes of stuff on toddpw.org
(and probably start with a progress doohicky for the i387 project once it
is hobbling enough to spend substantial time running unit tests).

Todd Whitesel
toddpw @ best.com