Path: utzoo!attcan!uunet!ogicse!ucsd!ucsdhub!hp-sdd!charles From: charles@hp-sdd.hp.com (Charles Keith) Newsgroups: comp.os.minix Subject: The Upgrade Process Keywords: upgrade process version patch 1.5.5 Message-ID: <3450@hp-sdd.hp.com> Date: 19 Mar 90 19:18:54 GMT Organization: Hewlett Packard, San Diego Lines: 64 Some weeks ago, a well meaning poster complained about the "busywork" of everyone doing upgrades. Having done 1.2 -> 1.3 on a floppy only system, I was interested, but not concerned. Now, having patched (but not compiled) 1.5.5, I am not only concerned, but a little upset. There seem to be two problems at work here: 1. The upgrade process is long, tedious and error prone. Once you are out of sync or have lost a file, endless time can be wasted trying to recover. If you get out of sync and lose the path back, the only recourse is to whine on the net (could somebody send me...), wasting bandwidth. 2. The upgrade postings were riddled with defects and errors. Each problem requires diagnosis and manual attention, and sometimes fiddling of the most desperate variety (perhaps if I add this line the crc will come out right). Andy's surprise that people could be having problems (the postings are all automated) are reminescent of the electric company's attitude when you get a $10,000 electric bill (but it's all computerized!:). Seriously, this kind of stuff is driving people away from minix, and soon only the captive audience (academics and students) will be left. The proposed solution was to identify and register Real Licensees and give them an easier way to upgrade. But unless administration suddenly becomes free, this will not work (think about the government). Rather than just whine about the sad state of affairs, I would prefer to propose solutions to the problems that bedevil us. Here are my (modest) proposals: 1. If the readership of this group is 10,000 as Andy suggests, perhaps we should all shout a suggestion in Andy's ear: TEST! Promise an undergraduate some extra credit and lock him/her up in a room with the old version and some upgrade postings. Remember, it is undergraduates that are supposed to suffer, not the world at large :). I certainly would be willing to wait an extra week or two if I were promised that things would go smoothly later. Problems with shar'ed binaries and empty files should never get out of the Netherlands. 2. Lift the ban on posting certain parts of the system in their entirety. For example, commands (which already has a high PD content) and lib (which is a chronic problem area). If this means they fall into the public domain, so be it. This will help enormously when someone gets out of sync, and the only recourse is to go back to P-H (we know how much fun that is:). The kernel/mm/fs has been less of a problem for upgrades, primarily because of limited size and the lavish attention paid to these areas. If these remain off-limits, it will be less likely for someone to (gasp) build a system from upgrades. 3. Create (graduate project) an automated upgrade system to compliment the automated posting system. This must be robust and well tested, and try to anticipate problems that would torpedo the process in midstream. Start with full crc checks on the old revision, make sure enough disk space is available, make the process restartable (or at least recoverable) if it crashes. Charles Keith Hewlett-Packard Co. UUCP: {hplabs|ucsd|hpfcla}!hp-sdd!charles 16399 W. Bernardo Dr. Internet: charles%hp-sdd@hplabs.HP.COM San Diego, CA 92127 Disclaimer: I am not a qualified spokesperson. -- Charles Keith Hewlett-Packard Co. UUCP: {hplabs|ucsd|hpfcla}!hp-sdd!charles 16399 W. Bernardo Dr. Internet: charles%hp-sdd@hplabs.HP.COM San Diego, CA 92127 Disclaimer: I am not a qualified spokesperson.