iSqueak

[Doug Way]

I think this makes a lot of sense.  The combination of Monticello & the
update stream sounds like it would be workable.

Also, I see that their initial packaging is reasonably coarse-grained,
which is good. :) (i.e. based on class category prefix, not class
category)

When you mentioned updating all packages to the "latest version" versus
"latest maintainer-approved version", I was thinking "we could use the
'published' flag for that", but oops, that's SqueakMap, not Monticello.
:)  But I agree that MC's more rigid/uniform packaging scheme is the way
to go for managing the base image.  We may need a few little enhacements
like that for MC, e.g. marking a version as maintainer-approved.  (Well,
maybe there's a way for the packages to automatically show up in
SqueakMap too.)

The initial maintainership model could err on the side of openness,
maybe even having some people with write access to all packages.  Then
we could restrict it a bit more later.

So, perhaps we should give it a go?

As Stephane said, who wants to set this up?

I confess that I mostly just have time to offer discussion and
coordination, and not much time for "real work" here other than perhaps
helping handle the update stream side of things.

- Doug


On Fri, 10 Jun 2005 14:38:11 +0200, "Avi Bryant" <avi.bryant at gmail.com>
said:
> 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