Message-Id: <199601151558.IAA01850@lager.beer.org>
To: Thor Lancelot Simon <tls@netbsd.org>
Cc: netbsd-developers@netbsd.org
Subject: Re: Goals/timeframe for 1.2? 
From: Herb Peyerl <hpeyerl@beer.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <1839.821721492.1@lager.beer.org>
Date: Mon, 15 Jan 1996 08:58:13 -0700
Sender: owner-netbsd-developers@NetBSD.ORG
Precedence: first-class

Thor Lancelot Simon <tls@NetBSD.ORG>  wrote:
 > Other features I (this is just a personal list) would like to see:  NFS v3,
 > Minnich's rfork() syscall (I think this is just a drop-in), IPv6, integration

I didn't think we were going to see an actual blessed version of any new IP 
code for another year or so... I mean, I'd like to see it in there as well 
but I don't know if anyone is going to want to tip their hand...

 > of the various network drivers that FreeBSD has that our i386 port doesn't,
 > a general exorcism of the NCR driver, and (if possible) integration of the ARM,
 > sun4m, and Alpha ports into the main source tree.  Oh -- now that there's an
 > IDE CDROM driver, it wouldn't hurt to have it along for the ride, and the
 > PCMCIA code too for that matter.

The problem with this approach, IMO, is that you're making a TODO list
and that might work in the commercial software industry but here we are
all volunteers who work on what we want to work on and forcing someone to 
work on something beyond that is not going to happen.

If you're going to generate a list of goals for the next release, then it should 
come from the developers themselves as a list of things they will commit to 
doing before the next release.

If you're going to do that, then you run the risk (more like 'eventuality') of
waiting for one or more items that someone isn't going to get done because 
they've suddenly got busy at work or are sick or dead or whatever..

 > If we're serious about more frequent releases, I think having a 10- or 12-item
 > checklist of features and perhaps a similar one of bugfixes for the next
 > minor-version release would be a really good idea.  Remember, these are *minor*

I think the current approach where a deadline is set by the REV (Release 
Engineering Victim) is the most appropriate approach given the circumstances.
I think everyone has their own personal goals and will probably generate 
their own personal list of things they'd like to do by the next release
but no one wants to be held to any of these things.