From owner-freebsd-hackers Thu Apr 20 12:30:04 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA07078 for hackers-outgoing; Thu, 20 Apr 1995 12:30:04 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA07072 for ; Thu, 20 Apr 1995 12:30:03 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.11/8.6.9) id PAA04694 for hackers@freebsd.org; Thu, 20 Apr 1995 15:32:02 -0400 From: Mark Hittinger Message-Id: <199504201932.PAA04694@ns1.win.net> Subject: Release stability (fwd) To: hackers@FreeBSD.org Date: Thu, 20 Apr 1995 15:32:02 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1289 Sender: hackers-owner@FreeBSD.org Precedence: bulk > From: Glen Foster > > If I remember correctly, the CSRG releases were "odd number == > features added, even number == stable versions of the odd number" > (actually, maybe it was the other way around :-). In the old DEC world there was a three piece cycle that was followed many times. A feature release followed by a robustness release. There was also a performance release that followed the robustness release. The focus was shifted during each release to concentrate on the primary goal of that release. Customers knew what to expect in general terms. We seem to be trying to do all three simultaneously and I don't think its really possible to do. You need a release just to purely fix bugs without having to deal with new features. You also need a release where you go back and look at those inefficient new features that were put in. Ok you have them working robustly now, but can they be tuned up? Continued thanks to the FreeBSD team for a fine piece of work. I am having lots of fun with it. If it is unstable I have the source, I have copies of the snaps, its my problem. This is *different* from the commercial OS where I don't have the source and it is still my problem :-). Been there - done that. Regards, Mark Hittinger bugs@win.net