Date: Mon, 23 Jul 2001 16:00:39 -0500 From: Mike Meyer <mwm@mired.org> To: Steve Lumos <slumos@nevada.edu>, "A. L. Meyers" <a.l.meyers@consult-meyers.com> Cc: freebsd-stable@FreeBSD.ORG, Max Khon <fjoe@iclub.nsu.ru> Subject: Re: is "stable" "stable"? Message-ID: <15196.36983.328968.125196@guru.mired.org> In-Reply-To: <200107231630.AHQ09490@100m.mpr200-2.esr.lvcm.net> References: <Pine.BSF.4.21.0107232334210.72827-100000@iclub.nsu.ru> <20010723185432.L376-100000@nomad.consult-meyers.com> <mike@adept.org> <Pine.BSF.4.21.0107222354320.68200-100000@snafu.adept.org> <200107231630.AHQ09490@100m.mpr200-2.esr.lvcm.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Lumos <slumos@nevada.edu> types: > Of course I butted in because I read the documentation and didn't get > out of it any indication that -STABLE wasn't where I wanted to be. > Certainly, the phrases: "the stable branch is effectively a bug-fix > stream relative to the previous release", and "[-RELEASE is] really > just a ``snapshot'' from the -STABLE branch that we put on CDROM," > sure sound like where I want to be. [Other changes deleted.] I don't have any real problems with those changes. You should PR them, rather than just sending them to the list. If you need help with that, let me know. A. L. Meyers <a.l.meyers@consult-meyers.com> types: > Now I am told that sysadmins should extensively test stable to > make sure it is stable. My conclusions: Any sysadmin who doesn't test new system software - no matter where it comes from - before putting it in production should be looking for a new career. How extensive the testing should be depends on what the software is being deployed on and how critical the application is. The testing described should be SOP for a mission critical application running on a load balancing server farm, even if you're running a commercial OS. A sysadmins job is to keep the system up and running properly. Software providers - being human - aren't perfect, so mistakes slip through. Even vendors of commercial software running on supported configurations of proprietary hardware sometimes miss a step. Any sysadmin who fails to test properly expecting the software vendor to do the sysadmins job is a fool. The biggest problem with FreeBSD -stable has been build errors due to incomplete or clashing MFC's. That's part of the price of tracking a development project. By their very nature, such things never break a production system, though they may delay a planned OS upgrade. Once you get beyond them, -stable breaks about as frequently as the commercial systems I've dealt with. I alternate between being amazed that the FreeBSD team has managed that, and being disgusted that the commercial vendors - who presumably have a proper testing matrix - don't do better. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15196.36983.328968.125196>