About MC for managing the image

[stéphane ducasse]

Hi

today I realized (I was idiot or totally into my envy/store  
practices) that we cannot
manage the image like we do for an application with MC (or we do not  
understand anything)
or Envy/Store. Here are the notes I took when going step by step over  
a releasing a new image with
marcus. I guess that it summarises somehow our questions and problems.

We (with marcus) are trying to understand how we can improve the way  
we harvest and produce
new images with the new process. Now we are a bit stuck  because I  
harvested too much. I always naively
thought that we could take 3.8 and load only the latest version +  
some changes that where done via cs.

But this is not possible for all the stuff
     - (1) that can only be done via cs,
     - (2) that one package may rely on another one that may rely on  
the other. (here I want to understand
     how MC can help see below)

So if I understand correctly this means that to arrive to version x,  
we have to load all the configs (hence the MC
deltas to speed up the process) until we load version x. I guess that  
this is the set up done at impara to manage iSqueak
and Tweak. Bert is it correct?

Now this means that this is really tedious to have to
     - define
     - validate
     - a load order for all the packages
     - publish a new cs on the update stream
     - publish a new image

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.

Bert what is the process that you have?

     Do you have something like getMeTheLatestConfiguration that  
worked from MC
     (I guess that what you have is the cs script that are in the  
update stream and scripts
     a working configuration)
     Do you have automated scripts?
     We have problems to really understand the MCConfigurationBrowser
     Can we programmatically filled up the MCConfigurationBrowser?

For the second problem (2) above Avi do you know if creating a  
package named Squeak with all the
subpackages as required would help minimizing the manual conflicts  
resolution. I thought that MC
was supporting an atomic load so I would like to use that as much as  
possible.

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?

What I like with required packages is that we version a configuration  
and the atomic load (if I was not dreaming)
Now with the scripts at the end of the process we have an image and  
in the cs the configurations.
Am'I correct?

Stef and marcus