About MC for managing the image

[Daniel Vainsencher]

stéphane ducasse wrote:
> 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. 
This is important in order to be able to do changes that require 
specific intermediate steps, exactly like what is planned for the entry 
of Traits into 3.9a.

> 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.
About creating the cs and new image - this should probably be automated. 
Something like
"write cs describing current image, get the last published image, load 
updates, save new image to web space".
I don't understand why the load order is necessary and what trial and 
error comes out of that.

But maybe Avi's response solves that part of the problem.

A couple of notes and proposals of my own -
1. I think one way to make you lives easier is to try to use only MC as 
much as possible. Tell people you accept only mcz/mcd files, for the 
existing packages. This will take time, but it will mean that people 
will think about their changes and what they affect, and its one less 
thing for you to figure out. If you get a CS, do you go over it manually 
and check that methods are marked as extensions where needed? if you 
require package versions, people are likelier to think of that themselves.
2. Use proper repositories, not Mantis. Mantis can contain a link to an 
mcz file in a repository, that is as easy for you to use as an 
attachment. But it helps accountability, because then anyone can get the 
original submitted version and inspect it. So tell people to put their 
versions up on source.squeakfoundation.org/inbox or to create themselves 
an account a personal project there, and then put up all their proposed 
changes as mcz files.
3. Tell everyone that care about maintaining the image to register for 
the sources.squeakfoundation.org RSS feed (I just found out about this). 
That way they get notified for every version that gets put out. That way 
people see what changes are proposed, and there's a better chance that 
good changes will be endorsed/extended, and bad changes will be seen and 
commented on. This is now the equivalent of reading the BFAV, except you 
can do it from Thunderbird.

This policy direction of moving towards using MC and SqS more 
exclusively for the management of the image are good because:
1. The current hybrid policy is too complex (as seen for example by the 
confusion caused by looking in changesets for traceability)
2. We can improve the MC tools to improve the image maintenance process.

For example, we can make one repository inspector that shows quickly all 
the new versions of everything that people suggest, and then harvesting 
will become easier in that way too.

Daniel