Hannes,

thanks for your motivating words.

> For the beginning even a relatively modest thing would be tremendously 
> helpful.
>
>
> ---------------------------------------------------------------
> The use case:
>
> a) take a base image (3.8g for example)
> b) follow a loading list (e.g. the packages for full)
> c) load a package and create an entry in a log text file
> d) do this until all packages are successfully loaded.
> e) send an email with the following notes to this list
>    (weekly)
>    the version of the base image, the packages loaded.
>
I think you identified a very important use case.
I assume that you mean the newest versions of this packages available, 
no?
So this would make sense on a moving target, meaning to try to load the 
newest versions into the _actual_ image version, right?
>    -----------------------------------------------------
> Result:
> The sucess of the test is indicated by a email
>
> Error:
> The process of loading may stuck. A crude and easy way to detect
> this is just a time out superwised by the calling shell script.
>
> The log file gives the last known package which loaded.
> An error report describing this is sent to the list as well.
> ---------------------------------------------------------------
>
>
>
>
> As a package loading list we could start with 'Full'
> and later add variants of it.
>
>
> Later one (when SM has dependencies) your test robot could go to 
> SqueakMap and load all the packages listed there as compatible with a 
> certain version. Developers could even check a box that they are 
> informed automatically if their package does not load.
>
> But for the moment we should limit ourselves to hand crafted package 
> loading list.
>
> If you manage to set up this Test Server again that would be a 
> tremendous contribution for the community. Notably one that safes each 
> one on the list a lot of trouble ....
Big thanks goes to Daniel Vainsencher, who installed it, and made work 
the first time! But somehow university got both of us distracted 
again...
>
>
>
> I do not see the fingerprint thing to be an issue. Just take the 
> images from the download directory. They are tagged with the change 
> set version number. For the beginning that is fine.
I did not explain it very well, I guess. The idea is to harvest all the 
unary methods (at least the ones on the class sides) and use them as 
"smoke tests".
Some of them might never run, but if some ran in an earlier version and 
now not anymore, that might mean sth.

In order to get them I was thinking to use this fingerprint approach, 
as you want to make sure, that no side-effects of some earlier tests 
occur.
For academic reasons I would be quite interested in this approach: has 
this been done before, is it useful, is it feasible?
>
> Thank you again for this initivative.
>
Thanks again for clarifying this useful use case and cheering words :-)

Markus