Hi Milan,

Thanks for taking the time to reply. Those do seem to be the available  
options, but I think I'd order them with #1 and #2 reversed. I think  
what we have now is the least desirable state of affairs. Further  
comment inline:

On 5-Jul-09, at 11:53 PM, Milan Zimmermann wrote:

> Colin,
>
> Thanks for taking a fresh look at this. My Etoys/Squeak  
> synchronization
> approaches are, from the "least desirable" to the "most desirable":
>
> #1. Remove Etoys from Squeak, as some suggested:
> 	- Cons and Questions: Where is the boundary between Morphic and  
> Etoys? Does
> it mean Morphic removal as well? What does it mean for Squeak in  
> education?
> 	- Pros: None for me. I voted for board individuals who I assumed  
> would not
> support this.

I think this implies that the Squeakland distribution remains separate  
from Squeak, and gradually diverges, as Squeak becomes less and less  
Etoys-compatible. It also means, I think, removing Etoys but not  
Morphic. The boundary can be somewhat arbitrary, and the freedom to  
break Etoys compatibility makes it easier to clean up Morphic over time.

> #2. Do nothing

Does this really mean nothing at all, or are you imagining that Squeak  
gets updated to the latest Etoys, even though we can't draw a line  
around it and manage it with Monticello? If you mean nothing at all,  
I'd say this is the least desirable scenario. If nobody is using the  
Etoys code in Squeak, it should be removed. On the other hand, if we  
can get Squeakland using a vanilla Squeak 3.11 (or whatever the  
release is called) it would be worth living with the kernel bloat for  
a while longer.

> #3. Achieve ability to Manage Etoys+Morphic as single Monticello  
> project.
> Unload existing Morphic+Etoys version from Squeak, and replace it  
> with the one
> in Etoys 4.0 image
> 	- Cons: Boundary between Morphic and Etoys remains undefined. Would  
> be nice,
> but it may be impossible given the time we have.
> 	- Pros: Refresh of Etoys (and some Morphic elements) from the work  
> made for
> OLPC in the last 2 years. This was a significant investment!

It seems like this could be done in the reverse as well - update  
Morphic/Etoys from the Etoys 4.0 image, then draw the line around it  
and make it a Monticello package.

> #4. Define Boundariies between Morphic and Etoys. Achieve ability to  
> Manage
> Morphic as one Monticello project and Etoys as a separate Monticello  
> project.
> Unload existing Morphic+Etoys version from Squeak, and replace at  
> least  Etoys
> from the Etoys 4.0 image
> 	- Cons: None for me. Except we may not have enough time to achieve  
> this...
> 	- Pros: Refresh of Etoys (and some Morphic elements) from the work  
> made for
> OLPC in the last 2 years. This was a significant investment! Ability  
> to manage
> Morphic and Etoys separately would unlock much potential (e.g.  
> replace Morphic
> with Morphic2 and keep Etoys functional on top of Morphic2)

Sure. This is definitely the ideal.

It occurs to me that your numbering could represent steps in a  
progression rather than a prioritizing mutually-exclusive  
possibilities. #1 has already been done, a few different ways.  
Understanding what gets removed when we create an image without Etoys  
is a good first step. Even more important are the changes that have to  
be made to the base image to keep it running correctly in the absence  
of Etoys.

#2 might be seen as porting the latest Etoys to a different base image  
- one with no Etoys present.

#3 and #4 are going to be difficult  no matter what, but they might be  
a bit easier if #1 and #2 have already been accomplished.

I don't have loads of spare time either, nor even the expertise in  
this area of the image. But I, too, would be willing to help. I think  
that achieving #4 is probably the most valuable thing we could put our  
collective effort into, now that the legal and social issues are  
largely fixed. Once our technical issues - of which Etoys is by far  
the largest - are sorted out, we'll be in a very good position to  
progress and grow as a community.

Colin