Date: Wed, 16 Oct 1996 12:43:46 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: rkw@dataplex.net, freebsd-hackers@freebsd.org Subject: Re: IP bugs in FreeBSD 2.1.5 Message-ID: <29484.845495026@time.cdrom.com> In-Reply-To: Your message of "Wed, 16 Oct 1996 13:23:30 CDT." <199610161823.NAA28163@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> this is true, and I am sure that you do too. However, my past > experience with the SNAP releases has generally been bad enough that > I am not willing to run them on production equipment, even when backed > up with a redundant system. They may be fine for desktop use, or And, as a BETA tester, I would never have expected you to. I fail to see how this is germain to the argument in question. > With a formalized RELEASE procedure, essentially what you are doing is > calling a feature freeze, cutting a "SNAP" (ALPHA), followed by one or > two more cleanup "SNAP"'s (BETA/GAMMA), followed by RELEASE. This And yet I would *never* have recommended that someone run ALPHA, BETA or GAMMA code on a production system. If you were doing this then you somehow missed the entire essence of what the process was supposed to be about. > Well, and this is sorta a critical concept, the fact that a given "SNAP" > is part of a formal release cycle makes it a very important SNAP. All SNAPs are part of the format release cycle. When a SNAP is getting particularly close to a *scheduled release* then I have always qualified that and tried to get folks to give it a little extra attention, and generally they have. Like I said, the system works for me and I'm going to stick with it. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29484.845495026>