From owner-freebsd-stable Thu Mar 16 13:35:24 2000 Delivered-To: freebsd-stable@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id A872E37B8CB; Thu, 16 Mar 2000 13:35:18 -0800 (PST) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id PAA15894; Thu, 16 Mar 2000 15:35:14 -0600 (CST) (envelope-from jeff-ml@mountin.net) Received: from dial-72.max1.wa.cyberlynk.net(207.227.118.72) by peak.mountin.net via smap (V1.3) id sma015889; Thu Mar 16 15:34:44 2000 Message-Id: <4.3.2.20000316151715.00b7f4f0@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 16 Mar 2000 15:32:36 -0600 To: Kris Kennaway , Jamie Norwood From: "Jeffrey J. Mountin" Subject: Re: which branch? Cc: Oleg Ogurok , freebsd-stable@FreeBSD.ORG In-Reply-To: References: <20000316123220.A90801@mushhaven.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:42 PM 3/16/00 -0800, Kris Kennaway wrote: >No, I didn't say <3.3 was unstable, I said that we recommend for the >ultra-conservative folks that they hold off jumping in the pool before >about then to give the pool-cleaners time to fish out the bugs. They wait about 6 months. About 2-4 weeks is sufficient for me. YMMV Still have system running 3.0R that is fairly reliable. Say "fairly" due to the vm bug that bites it once in a while. Knowing what generally causes it and how to catch it meant I never got around to updating. Bad yes, but it plays a minor role. Soon will be 4.0, but hope to be a bit more diligent upgrading. >This is how it's always been in FreeBSD and always will be: except by >getting the new release "out there" we don't have a hope of being able to >put it through all of the real-world testing which others can do. If you >think FreeBSD releases should be made with less bugs and higher quality, >you need to join the QA program and help find them before it goes out the >door so they can be fixed before, not after. Call me adventuresome, but I like to have at least one dot-oh release in production. Gives me time to adjust to new features, etc, etc. Not to start a big discussion on the release process (again), but for the QA team's sake there should be a day or 3 delay between the release tag and the grand send off to allow time for 11th hour problems. The few more problematic I saw were fixed. A minor ones remain, but need to rule out hardware/pilot error and none should be show stoppers for anyone. For those with non-critical needs I heartily recommend 4.0 release or stable. Much, much better than 3.0R's debut. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message