A roadmap for 3.9

lex at cc.gatech.edu lex at cc.gatech.edu
Mon Dec 13 18:26:35 UTC 2004


I think we should add more attention to the media stuff of Squeak, as
Mark has pointed out that we are overlooking thus for.

Before getting into that, though, let me wholeheartedly with Trygve's
comments.  No one should expect everyone to leap into their vision, most
especially people who are used to the way things are.  You either have
to invest the time to convince them your changes are good, or you have
to slave away in a monestary for years and then produce something that
is so overwhelmingly better that a large part of the other guys will
jump ship over to yours.  Squeak is already in the monestary compared to
many other computing systems, so I hope there is a way we can all
continue together.  I don't really see a problem with that happening, so
long as everyone understands that everyone else is not going to
immediately agree with them.

(This also suggests that, we might want to develop some sort of voting
system before too long.  I suggest looking at the organization of the
Debian project, as I usually do.  :))

Also, let me suggest a probable concensus item: everything on Stephane's
list is something every Squeak user would be like to be easily available
at some point in the future of Squeak.  It might not be in the base
image, but it should at least be easily installable.  What we are really
discussion here is what order to do things in.


Here's the twist I want to propose: for Squeak to be Squeak (see the
What is Squeak thread), we really need for the computer media goodies to
function.  That is Squeak's raison d'etre, and it's the primary reason
we should expect people to come and check out Squeak.  Further, the
secondary goal of being a good computer playground, will be well served
almost no matter what we do.  People trying to evolve the system, will
almost certainly want to tear apart whatever the initial image is,
anyway.  Further, people trying to evolve the system, will likely have
the chops to be able to load a few extra packages.  This is not true of
people who want to try the best personal computer-media system in the
world.  A graphics art major just is not going to spend the time to mess
around on SqueakMap loading extra packages and toggling preferences
before they can do anything.

Thus, I propose that very soon--3.9 or 3.10--we make a concerted effort
to get a really stable Squeak together for media users.  At the least,
all the play with me's should work, all the tutorials should work,
everything in the nu blue book that is feasible should work, and
everything in alan's talks should work and be accessible.  This is a
very doable goal, and it's a specific list of requirements.  Further, if
we do it right, then we can also develop a regression test suite to make
sure that this stuff keeps working in future versions.  Even if not, the
4.0 that Mark suggests would leave behind a 3.9 where all the media
stuff actually works; if we created a 4.0 right now, that is apparently
not the case.

Finally, let me agree that some of this stuff will indeed become
experimental hacks of the past.  This is not the case yet for EToys, the
MIDI synthesis stuff, and Wonderland.  Keeping these things working is
not sticking ourselves into the past; it's keeping true to Squeak's core
offering to its largest userbase.  Let's wait until *after* Croquet is
available, before we obsolete Wonderland and EToys.

(On the other hand, feel entirely free to dump MVC.  Why is dumping it
not on anyone's list?  If you want a lean Squeak, you should go back to
one of the 2.x's anyway.  It's one of the best ways imaginable to
simplify Squeak.)

What do people think?  Would anyone actually work on fixing etoy and
wonderland, etc., bugs, if that were the primary goal for Squeak 3.9 or
3.10?  Would anyone be interested in development test suites for these
kinds of things?  It sounds like an interesting research problem by
itself: how do you test that wonderland is still usable as it is
described in the nublue book?  It is likely to be partially manual, but
a lot could be automated as well.


Lex



PS -- and really, let's stop cleaning things if it breaks code. 
Cleaning by itself just isn't that valuable.  If you really think it's
worth the price of broken code, then pay the price yourself and fix the
stuff up.  At the least, check that everything in a full image still
works.  And ideally, try making a super-full image by loading everything
from SqueakMap, and seeing if *that* image still works.  Generally,
let's be very wary of creating more work for each other.

PPS -- there is absolutely nothing stopping us from having *three*
images moving forward, if we want: basic, full, and bernish.  (or maybe,
basic/media/systems).  Let's please not make basic more of a
battleground than it needs to be.



More information about the Squeak-dev mailing list