Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!UMIX.CC.UMICH.EDU!krowitz%richter
From: krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz)
Newsgroups: comp.sys.apollo
Subject: Re:  vt100 broken after patches
Message-ID: <9007101354.AA25169@richter.mit.edu>
Date: 10 Jul 90 13:54:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 44

Good God man! The patch tape release notes explicitly tell you *not*
to install patches unless you absolutely need them! This (obvious)
reason is that the individual patches have rarely had sufficient testing
in a complete OS environment on all hardware models. Start with a clean
OS release and install *only* the patches you *absolutely* need.

We've been a beta-test site for new OS releases for years now. A large
chunk of SR10.3 will be all of the patches for SR10.2 integrated into
a complete OS release. I can't tell you how *bad* the initial beta-test
releases tend to be, I don't have the room here. Let it suffice to say
that some models of hardware are usually completely unusable with the
first, second, or even the third beta release in the test sequence. Every
single patch has got to be tested on sau2 (DN3xx), sau3 (DSP80/90), sau4
(DN460/660), sau5 (DN5xx), sau6 (DN5xx-Turbo), sau7 (DN3500/4000/4500),
sau8 (DN3000/3010), sau9 (DN2500), and sau10 (DN10000) machines AND IN
ALL POSSIBLE COMBINATIONS ! (IE. diskless DN330 booted from DN560 is
different from diskless DN320 booted from DN3000).

This bring me to my final plea ... if you have particular problems with
the OS, volunteer to be a beta-test site. It's a *painful* process. Sometimes
the initial releases are so bad that my user's will stay away from the 
machines with the beta-software on them, and I wind up having to spend
a couple of days running quick tests on whatever I can think of before
I remove the beta-release, re-install the old OS, and call in the problems ...
but the only way the bugs will be fixed is if YOU find the bugs that affect
YOUR usage of the system and call them in BEFORE the *&&^%! thing is
released to the public. Thhis
This is particularly true of older systems ... The R&D people have the
latest and greatest hardware, not the older stuff, and they don't (and
won't) find the errors on the systems that they don't use. Take note
that "older stuff" means any DN560/570/580/590 (including 32MB Turbo
systems), any DN3000, any DSP80/90, any DN3xx -- practically anything
except DN3500/4500 and maybe DN2500 (the R&D people tend to get machines
with larger internal disks that the DN2500 holds). If you want the OS
tested with YOUR hardware, YOU have to do it 'cause R&D does not have
your hardware in house anymore.


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter.mit.edu@eddie.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)