From owner-freebsd-stable Thu Mar 19 15:21:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25035 for freebsd-stable-outgoing; Thu, 19 Mar 1998 15:21:20 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24953 for ; Thu, 19 Mar 1998 15:20:58 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id PAA11055; Thu, 19 Mar 1998 15:19:39 -0800 (PST) (envelope-from jkh@time.cdrom.com) To: Mike Smith cc: stable@FreeBSD.ORG Subject: Re: 'Code Freeze' In-reply-to: Your message of "Thu, 19 Mar 1998 14:14:57 PST." <199803192215.OAA26828@dingo.cdrom.com> Date: Thu, 19 Mar 1998 15:19:38 -0800 Message-ID: <11036.890349578@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > Let me just make one salient observation about this whole thread. Which is more comment than even I intended to make, this entire thread fitting the classic definition of "total waste of time", but now that the can of worms has been opened, let me just make a couple of additional points which some of the folks in the "delay it!" camp may find enlightening: 1. No matter how many people I've ever had screaming for a release to be delayed, I've had at least three times that many screaming at me to get off my ass and ship it. If you assume that the majority rules in most situations, this is a pretty strong argument in favor of shipping the damn thing. 2. Every release we've ever done, and I mean EVERY RELEASE, has had some fairly significant bugs - that's simply the nature of our volunteer development process. People's definition of "critical bug" also varies extremely widely and one man's definition of critical is frequently another man's yawn, and vice-versa. If I released only when nobody felt a pending release wasn't fatally flawed by their own definition then FreeBSD would never, ever be released. Period. If people also want to ensure that all but the most obscure bugs never again show up in a FreeBSD release then they can simply give me a few million bucks and I'll go out and create a large group of quality control engineers who, working to a schedule of approximately one release a year, using the time to regression test the living crap out of it and not letting the mainstream developers anywhere near their release candidate tree. It takes an awful long time to regression test an operating system if you're halfway serious about it and Sun, SGI, HP and others have all proven what happens when you rush a release out the door even when you HAVE an expensive QC department. Needless to say, the product of such a QC group would no longer bear much resemblance to FreeBSD so it's not really an option anyway. In any case, as Mike has already noted varying the length of the BETA test period has been historically proven to have NO EFFECT WHATSOEVER. I've tried 30 day BETAs, 60 day BETAs, I've tried ALPHA, BETA and GAMMA cycles, you name it and I've tried it. The only thing I've found to be true in all cases is that users are just too damn apathetic to be reasonable testers most of the time and the longer the testing period is, the greater their apathy since they don't feel any urgency about putting in the effort. I receive close to 75% of the truly useful feedback in the final week (or the week after) of the release, no matter how long or short the testing period is. That totally sucks, but it's also the way it is and it shows no sign of changing anytime soon. So, the long and the short of it is that there will be NO CHANGE to the 2.2.6 release cycle and you can all save your breath. If history is anything to go by, it wouldn't do a damn bit of good anyway and the only "purpose" that a delay would serve would be to piss off Walnut Creek CDROM who has to make hard-and-fast decisions about ordering print runs, reserving time at the replicators, etc. Everyone also bitches and whines when the CDs are late in shipping but nobody is willing to admit to it when the very cause of that lateness is our slipping our advertised schedule to get "just one more fix/feature in" and throwing WC's schedules into chaos. And if I sound just a bit embittered about this, it's because I am. Every release it's the same deal - I'm trying to push the cart to market and I've got maybe two or three people (out of god knows how many) asking "Hey, that looks heavy, where should I stand in helping you push that thing?" The rest just standing by the side of the road and offering helpful comments about how maybe going to market isn't such a good idea right now and we should just leave the cart in the middle of the road, or worse, they're full of lots of helpful engineering suggestions about how one goes about pushing carts more efficiently ("Help you push? Gosh no, I'd get dirty and besides, I have this bad back."). The release date is set and I don't want to hear another flippin' word about changing it - I already said very clearly in my BETA annoucement that I wanted this release to be ON TIME for a change and I'm sticking to that. If you've got some helpful feedback to give concerning testing that you're willing to do RIGHT NOW then great, it's still the BETA period and now is definitely the time for doing that. If you just want to make unhelpful comments about how buggered up previous releases were or make pontificating statements about how it's just not a good time to do it and gosh, you'd wait another month or two if you were me, then kindly put a sock in it because I have absolutely no interest in feedback of that nature - it and a buck will buy me a cup of coffee and this is the first and last message you're going to get from me on the topic. Oh, and have a nice day. :) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message