On Oct 17, 2006, at 7:49 AM, Lex Spoon wrote:

> "Pavel Krivanek" <squeak1 at continentalbrno.cz> writes:
>> Very good notes. This problems are described in the thread with  
>> Stef's
>> postmortem analysis
>> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- 
>> October/109807.html)
>
>
> It is just painful reading Stephane's description of package slices.
>
> Why not use Package Universes to organize a collection of package
> versions?  There would be a 3.10 release universe.  The release team
> would know the update password, and they could update that universe
> with new package versions as they see fit.

First, let me say that I'm all in favour of Package Universes. I  
think every release of Squeak should really be about creating a base  
image for a universe of packages.

However, I think there's been a bit of mis-understanding. "Slices" is  
the term I use in Monticello 2 for groups of program elements that  
define the contents of a snapshot. Like a package, a slice can  
produce a list of program elements, and answer questions about  
whether a given program element is included. Slices differ from  
packages in several ways, however.

First, the definition of a slice is opaque, and there can be  
different kinds of slices. There are PackageSlices, for example,  
which simply include all the elements of the package, and  
ChangeSetSlices, which include all the elements in a ChangeSet. I  
haven't gotten around to writing any other kinds, but it's easy to  
imagine things like SendersSlices, which include all the senders of a  
particular selector, or PrefixSlices, which would all the classes  
with a particular prefix, or even RewriteToolSlices that do RB-style  
pattern matching.

Second, slices are finer-grained than the packages we have now; they  
include variables separately from classes, and can thus extend  
classes with variables.

Finally, slices can overlap. A given program element can be part of  
many different slices, and this doesn't interfere with proper  
versioning the way it does with Monticello 1.

I think this last point is what Stéphane was talking about. Squeak  
3.9 was the first release that tried to do everything  in Monticello  
rather than using change sets. The big problem that came up was that  
most changes were spread across many packages. (This is hardly  
surprising, since the "packages" in the core image are pretty much  
arbitrary and have lots of entanglements and dependencies). This  
meant that any "update" would involve new versions of many packages,  
which would all have to be downloaded and merged. What used to take  
minutes now takes hours.

A second problem is that Monticello 1 doesn't deal well with methods  
moving between packages, which is precisely what has to happen for  
the kernel to be disentangled.

If the image were versioned using Monticello 2, these problems would  
disappear, since PackageSlices and ChangeSetSlices could be used side- 
by-side. Packages would become more and more independent over time,  
with change sets being used for cross-cutting changes, all the while  
maintaining version history and mergeability.

Anyway, slices are not meant to compete with Package Universes; they  
solve a completely different problem.

Colin