Date: Wed, 16 Oct 1996 15:06:29 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: freebsd-hackers@freebsd.org Subject: Re: IP bugs in FreeBSD 2.1.5 Message-ID: <199610162006.PAA28465@brasil.moneng.mei.com> In-Reply-To: <29484.845495026@time.cdrom.com> from "Jordan K. Hubbard" at Oct 16, 96 12:43:46 pm
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. The point was, I generally am not going to be willing to run a non- A/B/G/R release (i.e. other interim SNAP's) because they are often too flaky and the return on my investment is rather less than it might be. That is to say, if I can help eliminate bugs during an A/B/G/R release phase, that is (in my mind) truly productive and is not too "expensive" to me because there is much less work involved in upgrading to the soon-to-be-released RELEASE. If I simply install every SNAP, there is no guarantee that things will get better with the next SNAP, because perhaps you or whoever makes a small goof in some new feature bit of code that ends up blowing up the system consistently. That is where the "feature freeze" comes in. It essentially suggests to me that I am not going to be screwed over in this manner - the chances are very much in favor of a BETA release being better than an ALPHA release. The "time interval" gives me some time with which to actually test the release and perhaps find bugs beyond the obvious ones. It increases your chances for stability. > > 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. No, I did not. Jordan, I don't know how you think bugs get found, but in my experience they get found by people giving the code a workout. In order to get a stable "R" release, this means that the code has to be given a workout BEFORE the release - during the "A/B/G" phases. The essence of the process is that people are supposed to do everything that they can to break the A/B/G versions because once you get to the R version, you are stuck with it until the next release, six months off. > > 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. I guess I just haven't seen it work quite that way, but it's hard to say. The lack of formality sort of hides the process. :-( ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610162006.PAA28465>