Path: utzoo!attcan!uunet!mcsun!hp4nl!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The Upgrade Process
Keywords: upgrade process version patch 1.5.5
Message-ID: <6052@star.cs.vu.nl>
Date: 20 Mar 90 19:14:04 GMT
References: <3450@hp-sdd.hp.com>
Sender: news@cs.vu.nl
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 42

In article <3450@hp-sdd.hp.com> charles@hp-sdd.hp.com (Charles Keith) writes:
>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:
>
>Promise an undergraduate
>some extra credit and lock him/her up in a room with the old version and
>some upgrade postings.  
Won't fly.  MINIX is not really part of my regular work.  It is kind of a
hobby that I work on only in the evenings.  I don't have the authority to
lock up undergraduates and force them to test MINIX on pain of flunking out
if they don't.  Before making new versions, I post a local message to our
400 students to see if anybody wants to help.  Typically 1 or 2 students
show up, mostly because I give them 17 free diskettes.  Maybe they make a
couple of remarks later; maybe they don't.  Either way, there is little I
can do.  Undergraduates do not form a large pool of free labor.
>2. Lift the ban on posting certain parts of the system in their entirety.
I have posted whole files from time to time, and even whole directories
(e.g., /usr/include).  Given that many of the postings, certainly the recent
ones, have only been bits and pieces of files, that won't help much.  Also,
I don't think P-H would approve.

>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.
We do have graduate projects, but this is not a suitable one.  Such projects
must have a high research component.  Automating updating is not a good choice.
Typical projects have been redoing a new 'make-like' program that runs all
its compilations in parallel on a distributed system using Amoeba, writing
a parallel chess program in Orca (our new parallel programming language), or
writing a very fast C compiler for the SPARC using ACK.

In short, I do not have a lot of captive manpower (in fact, none) at my
disposal.  It's just me, and then only in the evenings.  This is kind of
different than companies that have rooms full of programmers working for them.
If you or anyone else in Netland wants to work on a system
that takes two source trees and posts the diffs along with another system
that installs them, I am not averse to it.

Andy Tanenbaum (ast@cs.vu.nl)