updates vs. images

Avi Bryant avi.bryant at gmail.com
Wed Oct 12 22:11:16 UTC 2005


To throw some new (and maybe novel) fuel on the recent fires around  
harvesting and the update stream:  why do we need an update stream at  
all?

Other Smalltalks - VisualWorks, Dolphin, etc - simply release new  
images when there are new versions, and everyone is expected to  
reinstall their code into that.  Bootstrapping problems have to be  
solved once, by the vendor, and everyone uses the same resulting  
image.  As long as it's simple enough to load your own packages in -  
and Monticello at least handles *that* pretty well - this should be  
pretty easy for the user.  In practice, in fact, this is exactly what  
I do already - I just download the latest image Marcus puts out and  
go from there.  I suspect lots of others do the same thing.

Now, I realize that the update stream is more important for some  
segments of the Squeak community than for others.  In Squeakland,  
most of the interesting content cannot be captured by a Monticello  
package, and is at least somewhat harder to load into a new image -  
and so the desire to update the existing image is stronger than it  
would be for those of us doing "code-only" work.  I imagine similar  
concerns apply in the Tweak world, and I'm sure they do for Croquet.   
But then, don't those groups maintain update streams separate from  
what I guess we could call the "Squeak Foundation stream" already?  I  
doubt things would change much there no matter what SqF did with its  
stream, including getting rid of it entirely.

The reason that I propose this is that the sense I get from Marcus  
and Stef and others involved in the harvesting process is that the  
main difficulty is not one of evaluating and integrating changes, but  
of preparing those changes for the stream.  Generally, it's easy for  
someone to produce a single image that's properly integrated, and  
even to record that state in a set of package versions suitable for  
people to submit changes against for later integration.  What's slow  
and unreliable is setting things up so that some other arbitrary  
image can go through the "same" set of changes.  Frankly, although  
Monticello is a pretty decent tool for development work - it handles  
submitting and integrating changes fairly well - it's showing itself  
to be a really bad tool for deploying changes.  On the other hand,  
images are a *great* deployment mechanism.

Thoughts?

Avi



More information about the Squeak-dev mailing list