Hi everyone.

I think improving the process for those doing the development is 
important, but agree with Andreas that the current proposal sounds like 
we're giving up on users ability to update their images. If that's what 
we want, we should just say so.

If we're going to go for a better system that has the benefits of MC and 
supports image updates, we need to actually catalog, discuss, and solve 
those nitty gritty problems that bug both sides of the development 
process at the moment. And this will be a lot of work, and we can't 
expect the MC guys to just solve it all for us, even if MC2 solves the 
code issues, including performance and class-renames.

Before continuing with the bad news, just wanted to remind ourselves 
that systematic treatment of live system updates is possible at least in 
the sense that GemStone does it.

Here is a partial list of problems I met while working on the updates 
for Traits:
- Having made some changes, I should know whether these are loadable 
into a published image. This currently requires manually posting, 
opening new image, loading. Some test server seems useful in this context.
- Doing live updates correctly requires capturing a sequence of steps 
which know enough each about the previous state to keep things running 
correctly. MC by itself does not model this at all. An external tool 
(ScriptLoader, IIRC, in the current process) can capture this. But in 
addition to capturing update sequences, we need to be able to merge 
them. For example, suppose we and Squeakland create two unrelated update 
sequences for overlapping sets of packages, starting from common state 
A, going to B and C respectively, through B1, B2... and C1, C2... The 
"did-both-updates" state D needs to be created (probably via MC merge), 
but what are the stage D1,D2...? It might well be that the merge problem 
needs to be solved manually, rather than automatically, but we 
definitely need a better way to detect it, to capture the sequences, and 
to change from one sequence to the other when we find problems 
(currently doable only by updating the updates-list file, AFAIK).
- Recompiling the whole image is very slow. Therefore changing the shape 
of many classes (in that example, all metaclasses) makes updates take a 
very long time.
- It is hard to make some system level changes because none of the 
existing tools in the image document all the VM assumptions. Therefore, 
that bug from changing the shape of Behaviors that prevents some 
primitives from running.

Daniel Vainsencher

Andreas Raab wrote:

> Cees de Groot wrote:
>
>> Personally, I would point my finger at the use of MC instead of MC
>> itself (MC seems to be not fit for a particular purpose its creators
>> probably never reckoned with).
>
>
> According to Colin "Monticello was designed with maintaining live 
> system in mind" (see 
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-February/101067.html) 
>
>
>> Anyway, I wasn't assigning "blame", I
>> was just remarking that there was a conflict here.
>
>
> Me neither. As I've said in the past, MC is good for what MC is good 
> for (namely managing source code in a "build" environment) but it 
> strikes me that you're proposing to apply it in just the way where it 
> doesn't work very well. But of course, that's just my experience. YMMV.
>
>> Nope. My idea is that during "fast development", the team leader just
>> publishes images. And probably an MCC map or something similar showing
>> how the image is put together. So the user would effectively have to
>> download the image to hop across major upgrades. Minor upgrades would
>> likely be doable by just udating using the MCC map. For some value of
>> "major" and "minor", of course :)
>
>
> Um ... I might be slow or something but can you explain to me again 
> how this makes things simpler/easier/whatever? Where is (in terms of 
> pain associated with it) the difference between having that MCC map 
> and posting it to an update stream? (unless you don't do it at all ;-)
>
> And using images this way ... uh, oh. I have a *really* bad feeling 
> about this one. You're right, it's often easier to do things in your 
> image and distribute that image. It's also a sure way of making it 
> impossible for anyone to track ongoing development, the release 
> progress, and the history of how things evolved in the image. All of 
> which are (in my understanding) very desirable properties. I fear that 
> this will lead to a process where you hand off "the image vX.Y" to a 
> small group of people (possibly one) and get back "the image vX.Y+1" 
> and hardly anyone will have looked at anything at all, noticed the 
> oddities, which clean ups are required along the way etc. Not saying 
> that many people today track the changes very closely but I even that 
> seems preferrable to a process where you don't get to see anything and 
> have no documentation of the changes the "official" image went through.
>
>> Yes, that's bad (for people with low bandwidth, for starters).
>> However, it buys time to fix the issues with Monticello, so that
>> hopefully later on a "upgrade v.X to v.Y" button can be reinstated. 
>
>
> Nice try. You know just as well as I do that this ain't gonna happen 
> ;-) If only because when you give people the ability to modify an 
> image "at home" they'll use it for *precisely* those changes that are 
> hard to deal with in Monticello. Otherwise, why not use Monticello to 
> begin with?
>
> Cheers,
>   - Andreas
>