A process proposal for 3.10

Giovanni Corriga giovanni at corriga.net
Mon Oct 16 13:55:50 UTC 2006

Il giorno lun, 16/10/2006 alle 07.49 -0500, Ralph Johnson ha scritto:
> Many packages in Squeak cannot be deleted easily.  This is because
> Squeak is a monolithic system without clear modules.
> So, the rule "If they can't find a mantainer for a package, than said
> package _will get dropped from the image_ without any further
> discussion" must be changed.
> I propose "If a package doesn't have a maintainer and it is possible
> to remove it from the image without breaking the image then it will be
> removed."

Sounds reasonable.

> By the way, what is a package in Squeak?  One kind of package is
> something available from SqueakMap.  These are easy to understand.
> They are not the kind of packages that cause problems.  You are
> talking about things like the compiler and collections as being
> packages.  Is there a list of packages in Squeak?

What we're talking about is Monticello packages. A Monticello is a set
of classes with the same "major" class category, plus a set of
extensions - methods defined by the package in classes that don't belong
to the package. those extensions methods have a method cathegory that
starts with a star (*) and the package name.

Example: if in the latest Squeak release you browse the instance methods
of class Behavior, you'll see a method cathegory named
"*system-support". Those methods are extensions belonging to the System

The problem with things like Etoys is that they're highly coupled with
the rest of the system, and part of the system depend on it. For
example, trying to remove Etoys triggers an emergency evaluator in
Squeak 3.9RC2. As I see it, if we want to remove Etoys (and either let
it rot in absence of a mantainer or turn it into an installable
package), those couplings would become bugs for the other package


More information about the Squeak-dev mailing list