iSqueak

[Avi Bryant]

Hi all,

Sorry for the long silence on this list - I've been negligent in my
team leadership duties by not keeping the discussion going (for
example, I think Lex posted a status report that should have been
forwarded to squeak-dev but was instead completely ignored - sorry
about that).

However, it seems that if you ignore a problem long enough, eventually
someone else will solve it for you.  I thought the recent traffic on
the list about Tweak's approach to managing updates and packaging was
very relevant: it sounds like Impara have come up with a system that
nicely balances Monticello and the update stream, and that actually
works.  If you didn't see the original message from Andreas, here's
the important bit:

"In Tweak, *all* code is in packages[*]. Updates are
exclusively used for in-image reshapes, e.g., when part of the system
has undergone significant changes that require manual intervention. In
order to synchronize these modifications with the package versions that
we expect, we typically post a configuration map, e.g., a list of
packages where we expect some specific version to be present.

When you update, we always consult the update stream first. This will
suck in any intermediate configurations and perform the necessary
in-image modifications. Once this is done, we merely upgrade all
packages in a well-defined order to their latest version."

Moreover, they've come up with an initial packaging for Squeak 3.8,
available at http://source.impara.de/iSqueak.html (see the wiki tab
for info and downloads).

I think this is great work, and I'd like to suggest that we adopt it
as the basis for the partitioning/packaging efforts in this team. 
This would mean, probably, these steps:

- We adopt the reorganization changeset from iSqueak as the first
packaging changeset to go into the 3.9 stream
- We include Monticello and Impara's MonticelloConfigurations as base
packages in 3.9
- We set up an initial repository (probably based on SqueakSource) for
the resulting Squeak packages, which anyone on this team can commit
to, and start committing the results of any further partitioning work
to it
- We hack the repository as needed to support whatever kind of
maintainership model we want for the Squeak packages.  Tweak lives in
a fairly closed world, where it's reasonable for everyone to update to
the latest version everyone has posted, but Squeak (probably) can't do
that.  So instead of "upgrade all packages in a well-defined order to
their latest version", we probably need "to their latest
maintainer-approved version", and have a harvesting process that turns
submitted versions to approved versions.  We may find that the
"blessing" mechanism I developed for the UnstableSqueak project is a
good step in this direction, but we should talk about it more.

Thoughts?

Avi