From owner-freebsd-hackers  Sat Apr 12 15:56:09 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id PAA28695
          for hackers-outgoing; Sat, 12 Apr 1997 15:56:09 -0700 (PDT)
Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA28689
          for <hackers@freebsd.org>; Sat, 12 Apr 1997 15:56:03 -0700 (PDT)
Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id TAA16831; Sat, 12 Apr 1997 19:00:59 -0400 (EDT)
Message-Id: <3.0.32.19970412185325.00b30650@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 12 Apr 1997 18:53:28 -0400
To: Terry Lambert <terry@lambert.org>
From: dennis <dennis@etinc.com>
Subject: Re: Commercial vendors registry
Cc: terry@lambert.org, scrappy@hub.org, pgiffuni@fps.biblos.unal.edu.co,
        hackers@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 01:21 PM 4/12/97 -0700, Terry Lambert wrote:
>> >OK, you lost me here.
>> >
>> >If I hack on a release, it's no longer a release, it's a -current.
>> >All new work following a release must be, by definition, done against
>> >a -current, not against the release.
>> 
>> There's too much "its fixed in -current" or "it'll be in the next release" 
>> and not enough commitment to getting fixes and important new feature
>> into the short-term.
>
>Fixes, maybe, if they were treated as releases themselves, and could
>be applied to non-stock systems.
>
>But "important new features"?  No way... a new feature waits for
>a release.  Releases are *defined* by a feature freeze.  Add a
>new feature, and once again, you have a -current.

I said "short-term", which implied 2.3, not 3.0 in 1998. 


db