updates vs. images

stéphane ducasse ducasse at iam.unibe.ch
Thu Oct 13 06:30:08 UTC 2005


Hi avi

please note that I was not complaining about MC.
I think that what you are doing is good and I trust you for that.
My problem is more at the brute force level of good people spending  
time fixing important part of Squeak.

> 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.
>

This is true.


> 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?
>

I agree.
I think that besides bugs that get in our way we go in the right  
direction, even if better navigation possibilities in MC
would be great.

My problem is more:
     when do we get real nasty bugs kill?
     Semaphore revisited, weakDict or weakArray....

Stef

>
> Avi
>
>
>





More information about the Squeak-dev mailing list