Lex said...

> Keep in mind that we have multiple projects using Squeak.  For some, MVC
> is fine.  For myself, MVC is attrocious and Morphic is a massive
> improvement.  (regarding speed, load a 3.0 image sometime and see how
> fast morphic *can* go....)  And for others--perhaps the *majority* of
> Squeak users -- EToys is where it is at.  A Squeak without EToys is a no
> go for the general population.  At best, such a Squeak is a fork.

I perfectly understand this. I just believe "standard", "basic", "minimal"
or whatever should not include eToys. And probably not even Morphic.
All these should be loadable packages. Of course, pre-made distros with
eToys or whatever a set of users want would be good. But made by loading
optional packages form a suitable Universe to the small main standard image.

> The Cees approach of start fresh sounds very promissing, except that I
> am afraid no one will step up to actually port across all the important
> functionality -- like Morphic and EToys -- that many users want.  If we
> don't have people packagizing this stuff, then will we really have
> people porting it across?  It is not clear that we will, which means we
> would end up leaving behind important functionality.  We would have even
> more Squeakers using old Squeak versions, than we do currently.
> Essentially, that approach would be to do the fork Mark Guzdial
> mentioned in the "What is Squeak?" thread.  It's not a terrible
> solution, but why go down that path *just* to have small images?

I heartfully agree with Cees aproach. Back compatibility is a pain in
the butt. Let's keep maintainig what people actually uses, and let's
start leaving behind stuff that is old, buggy, unmaintained, incomplete,
unused, etc.

I am volunteering for developing and maintainig the Morphic package.
I'm sure someone will volunteer for developing and maintaining the eToys
package. (Or maybe they all decide to move move to Tweak).
There is no need to fork. In fact, this is not just to have small images.
It actually is to avoid forks!
I really can't work with eToys in. If the community chooses to keep
the big base image, at least I will need to fork, and just keep using
my 3.7 eToys freee image.

> Juan, your work on extracting Etoys is excellent, even if it did take
> out a few extra pieces along with it.  I hope that it gets turned into a
> loadable and unloadable package; it shouldn't be so hard, now that
> you've identified the list of stuff!

I have no problem with refining it so it's just the removal of eToys and
nothing else. But I don't think making it a loadable module is a great
idea. It would have the same problems that the shrinking methods have.
I prefer growing a small image than shrinking a big one.
And making it unloadable again (to load back eToys!) seems rather
strange to me.

> One last thing to keep in mind.  Things that are used a lot, become easy
> in Squeak.  Shrinking sucks right now because hardly anyone is
> interested enough to really work on it.  People are voting in a very
> honest way: how they spend their time.

I believe the big decision  to make is: Do we prefer shrinking a big image
or adding packages to a small one? I vote for the second.

> -Lex
>

Juan