From owner-freebsd-stable Wed Mar 18 10:01:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21907 for freebsd-stable-outgoing; Wed, 18 Mar 1998 10:01:13 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21897 for ; Wed, 18 Mar 1998 10:01:02 -0800 (PST) (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id KAA21709; Wed, 18 Mar 1998 10:59:28 -0700 (MST) From: Wes Peters - Softweyr LLC Message-Id: <199803181759.KAA21709@xmission.xmission.com> Subject: Re: 'Code Freeze' To: mvh@netcom.com (Michael V. Harding) Date: Wed, 18 Mar 1998 10:59:27 -0700 (MST) Cc: stable@FreeBSD.ORG In-Reply-To: <199803181311.FAA02549@netcom1.netcom.com> from "Michael V. Harding" at Mar 18, 98 05:11:14 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk Michael V. Harding opined: > I'll have to agree with the below - my experience has been that the > CDs are the LEAST stable releases. Also, look at this slice code > change - it was introduced either after the code freeze, or right > before it. The CDs should have a longer test period, maybe a month of > real code freeze. I realize that this makes things harder for > developers, but the stability of the CD release is very important - > this is how most people get introduced to FreeBSD. > > > Absolutely the worst thing any developer can do is to rush code into a > release at the last minute. The current practice of announcing release code > freezes encourages precisely that bad behavior. The result to a long time CD > subscriber like myself is that I have _never_ received a FreeBSD CD that is > useful to me by itself. There always seems to be some ugly bug discovered > within a month of the CD going to press that requires me to use the CD only > as a bootstrap method to get to current STABLE -- which is always reasonably > stable, unless Jordan has announced a code freeze recently. > I unfortunately have to agree, the last several CD releases have been unstable enough that even I had to update to -stable a month or so after the release, and I am relatively undemanding of my FreeBSD systems. (They are primarily used as cross-development systems for my embedded work). Perhaps we need to introduce a more defined release structure, where the release is announced with a 4 to 6 week 'alpha' phase, where final features are introduced, a 4 to 6 week 'beta' phase, where only bug fixes and removal of unstable alpha features is performed, and then a 2 to 4 week 'Early Availability' or 'FCS' phase is closely monitored, prior to pressing the CDs. I offer this not as a criticism of the excellent work already done by the FreeBSD team, but as an observation from an experienced engineer who has fathered a couple of commercial products through the growth that FreeBSD is now experiencing. As the product and the customer base grows, and the variety of installed systems grows, the release processes must grow to keep up. Unfortunately, this makes them take longer as well, but that is inevitable. Another suggestion I have is to *not* do the release preparation on the -stable branch. I know this adds yet another branch to an already large development tree, but history has shown that once we start the integrate-athon that happens before every release, stability wanes for a time. To me, the preparation for a release has *nothing* to do with maintaining a stable tree, and therefore shouldn't break people who want to cvsup -stable to keep their systems up to date. Many thanks again to everyone who contributes to FreeBSD, and most especially the core team. This is a marvelous work you have created. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message