Hi All.

This is a piece of a response inspired by James post
(Adult Etoys). It needed to be in its own mail piece.
I seem to be posting the pieces bottom to top from a
long draft reply. So see future posts for more
context.

----

Now where did I put that soap box? I am feeling the
itching need for it. Ah, here it is.

Update stream are essential!!!

Currently 3.9 has done the development a great
disservice by choosing to force maintenence of ALL
code in the image as MC packages.
Remember what I said about big steps versus lots of
small incremental ones?

This is a life destroying decision for the squeak
community.

Look at how fast the OPLC team develops improvements
and look at the level of feedback they get.

Now compare that with the glacial pace of the squeak
image. 
We have the best people I can imagine working on the
release team. There has been no alpha image release
and there is no way for test-pilots (alpha image user
and testers) to obtain an alpha image or give feedback
on it.

The release teams have gotten mired in redefining the
process of getting fixes and patches into squeak and
it looks like they will remain that way for several
releases to come.  The painful part of the problem is
that 3.9 started to burn the bridges to the old
processes.  

The number of fixes for painful problems in Squeak are
sitting on mantis rather than being available in an
update stream or thru an update list. The debugging
tool of having access to previous versions of methods
and a history of what was tried has been scuttled, not
deliberately, but because of unfortunate decisions
made early in the 3.9 release process and the cascade
of their consequences. 

A lot of this would be resolved if a process for
making updates would include update streams (and
change sets) as the last word in developing images.

Build all you want from mcz or mcd files but then
allow updates from an update stream.

Dealing with package changes. If you can save an image
to disk, it should equally be possible to save an
image to disk as componentized packages. If it takes
considerably longer to save the components than the
image then what does that say about the whole notion
of componentizing the image?

One test any final candidate should be able to pass is
to be savable to disk. and then to be component
saveable to disk and component loadable (from a
kernel?) getting back an equivalent if not identical
image.

Doable? 
My low opinion of MC (in the context of image
maintainence) is that 
if there was a test.
it would not work.
if it did work it would take so much more time to
split/reassemble an image in that way that no one
would desire to spend the time to test it. 
======

Thank you for your patience and interest. Let me put
the soapbox's away for a while.

========

Yours in service, --Jerome Peace


 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com