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