About MC for managing the image

[Andreas Raab]

Hi -

> The implications with this setup is that we have to produce often an 
> image (validate a configuration of changes working together) and 
 > this can be quite painful. At least they are a lot of try and error
> when there are a lot of dependencies between packages.

In my experience that's a sign that a) you haven't found a good package 
structure and/or b) you don't test early enough. In the first case the 
effect is that higher-level changes get intermangled with lower-level 
changes (that do in fact require careful folding into a running system). 
An indication towards that point is the effect that the Kernel package 
has (I think) the most revisions, where clearly it is one of the most 
stable packages (if it isn't we're in big trouble) and should have the 
least number of modifications. The same is probably true for Morphic at 
this point - you *need* a better package structure for Morphic which 
makes clear when you touch the critical parts (requiring very careful 
testing) and when the non-critical ones. In comparison, in Tweak I can 
typically tell by just looking at the package name whether this will 
require any effort to make sure it loads correctly or not.

It is also really important to test "early enough" whether you can load 
a package or not after you've done a modification. Unfortunately, you 
guys are somewhat handicapped since you don't have an automatic default 
update mechanism like we're using in Tweak. When I post a new version of 
a package that has even the slightest chance to affect anything I 
immediately get a fresh image, hit update and test it. Cost me perhaps 
twenty seconds but if it doesn't work I can easily either post an 
appropriate configuration or make a change to the package to make it 
load and post a new version of the package. I really couldn't imagine to 
work like you do, e.g., make a whole set of new package versions, try to 
load and figure out where and why it dies.

> Bert I have the impression that using package dependencies with a 
 > root package (ie havgin Squeak and all the image package as
 > required) would help to minimize inter package dependencies,
 > now why do you use your script (the explicit  list of packages)
> instead of required package. Is it because you can push that in the
 > update stream?

Early on we looked at using dependencies but they didn't work very well 
for what we wanted to do. Most importantly, if you have a newer version 
of a package it will load the older version instead (VERY bad). There 
were also some serious issues with nested dependencies (Bert and I had a 
lot of fun figuring that out). And keep in mind that dependencies are 
not as good as a load-order since they typically only specify a partial 
  relation (A dependsOn: X and B dependsOn: X does not specify whether A 
is loaded before B or vice versa) whereas we wanted to make sure that 
the updating process uses a single well-defined load order for everyone.

Cheers,
   - Andreas