Date: Wed, 16 Oct 1996 13:23:30 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: rkw@dataplex.net, jgreco@brasil.moneng.mei.com, freebsd-hackers@freebsd.org Subject: Re: IP bugs in FreeBSD 2.1.5 Message-ID: <199610161823.NAA28163@brasil.moneng.mei.com> In-Reply-To: <27935.845485602@time.cdrom.com> from "Jordan K. Hubbard" at Oct 16, 96 10:06:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> That's simply because you haven't kept up to date with events. The > whole ALPHA/BETA naming cycle was *discontinued* just as soon as I > started making 2.2-current (and even one or two 2.1-stable) snapshots > regularly. They filled the same niche, and the whole ALPHA/BETA > system was falling apart anyway due to a lack of concerted testing. Hi Jordan, You can add me to the list of people who haven't kept up to date with events (or, perhaps, forgot)... because this takes me by suprise too. > [...] > After an especially weak BETA, I decided that what was needed was more > of a "regular train" system, which made frequent stops and let anyone > hop on or off along the way, as time and inclination permitted. This > became the SNAPs and the rest is history - it's worked out, on the > whole, a lot better than the ALPHA/BETA cycles as less on-demand time > is required for testing. If you've got a final bang in the middle of > one SNAP, you wait for the next one. A view from the other side: As one of the original folks who did put a lot of effort into ALPHA/BETA/GAMMA testing, I have a harder time with this, and I will try to explain to you why. The SNAP's are a great mechanism to facilitate interrelease "testing" and "early access to new bits". I absolutely and strongly feel that 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 casual use, but my confidence level is very low. 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 happens with predefined minimal time intervals between each stage, and with certain guidelines for quality control (i.e. you do not proceed to the next stage until stupid, easy to correct problems present in the current stage have been fixed). Soooooooooooooo, you say, and so do I. The current procedure may give you much of that. So what's in a name? 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. What happens when your ALPHA/BETA testers do not recognize it as such? I will gladly go to great inconvenience to test 2.2ALPHA, but if I do not recognize 2.2.0-961020-SNAP as an "alpha" snap destined to become a release, I may not be able to help you test it. I try to glance over all the SNAP announcements, but I can't swear I'll see them. I am much more likely to notice a 2.2ALPHA announcement, or references to 2.2ALPHA on the mailing lists. Being a part of a formal release procedure means that you are in FEATURE FREEZE, where you do not make questionable changes or add extra features... and what you DO do is done with a LOT of careful consideration and peer review and testing. Being a part of a formal release procedure means that you release your A/B/G releases, with a predefined time interval between each one, to allow people to install and test the system. If you look at it from a larger point of view, it is not so much about naming as it is about discipline. The naming follows the discipline and can reinforce the formal release procedure. But I maintain that FreeBSD's release discipline - while never very good (often rushed due to various pressures) - has sunk to new lows in the last year or so. Right now, I have no idea when a particular SNAP is worthy of my going to lots of trouble to test it. I have no idea when the next RELEASE may be coming out, and there is very little incentive to try a SNAP on one of my big machines. With a formal release procedure, I know when the ALPHA release comes out that the next RELEASE is anticipated in about X weeks, give or take a little bit, and I know that we are in feature freeze and it would be extremely helpful for me to try out this version. I would rather see RELEASE cycles more often (maybe every three months instead of every six), and I would prefer to see them be rigorous and formal. I would even settle for just the added rigor and formality. This need not be an entirely different way of doing things... it could simply be extending your SNAP paradigm appropriately to encompass these elements of good software release procedure. I think it would be a great benefit. My opinion, ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610161823.NAA28163>