From owner-freebsd-current Wed Dec 3 04:03:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA03128 for current-outgoing; Wed, 3 Dec 1997 04:03:02 -0800 (PST) (envelope-from owner-freebsd-current) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA03122 for ; Wed, 3 Dec 1997 04:02:56 -0800 (PST) (envelope-from dyson@freebsd.org) Received: (qmail 2835 invoked from network); 3 Dec 1997 12:02:52 -0000 Received: from dyson.iquest.net (HELO freebsd.org) (198.70.144.127) by iquest3.iquest.net with SMTP; 3 Dec 1997 12:02:52 -0000 Message-ID: <34854A60.829AB149@freebsd.org> Date: Wed, 03 Dec 1997 12:02:40 +0000 From: "John S. Dyson" X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: Amancio Hasty , Greg Lehey , FreeBSD current users Subject: Re: 3.0 -release ? References: <6959.881142325@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I believe that it is *critical* that we don't set up any false hopes, and extolling the virtues of half baked code is something to avoid. Some of my code has been in that category, and I hope that we have learned from those mistakes. It is okay, for example, given the state of the code, for us to say that SMP works in -current. That warns the users of the beta or even incomplete nature of the implementation. More and more, we are in the position of FreeBSD's performance and quality being "paraphrased: better than expected", but of course not perfect. I hope that we stay in that position. Perhaps we are getting more conservative, but that is probably natural given the project's maturing. One thing for sure, if we start becoming overly conservative and stagnent, I will be one to try to push things along. I tend to agree with the position that we have more time to go before 3.0 is ready... Those users who really really want SMP, kernel threads, AIO or whatever fancy new feature that is going into -current will have to realize that the code is pre-release and immature, and tracking the code will require more effort than code that is released and stabilized. Here is a case in point, I just committed a "fix" to support the MS_SYNC msync flag. The logical value for it is "0", at least a couple of commercial U**X's have chosen "0", but a couple of other free U**X's have chosen "4". The value that I chose *might* be changed, and if it is, it will have been because of good reasons. Someone using the code in production will likely not be too pleased by such a change, but we need the freedom to issue such corrections. -Current is just not ready for release, and there is alot to do for us to meet reasonable goals for 3.0. It is possible that a release could occur before *everything* is done, but that is a bridge that doesn't appear to be time to cross. John