I actually like that you do not refer to groups of packages from
within code, nor that there are not a lot of operations on groups of
packages.  There is dependency satisfaction, and that's about it.
There is an image-wide set of packages, and an image-wide set of
tests.  Loading new packages and new tests simply adds to these sets.


The self tests included in packages fit in as a great sanity check
that a package is working in its current installation.  Note that
packages are developed independently, and that new versions are posted
all the time.  Additionally, different people load different
combinations of packages.  Self tests are important because a package
might test out fine on the developer's desktop, but still fail to work
when it is loaded on someone else's machine.


For these self tests to work, though, you need to know which test
failures really matter.  Ralph reports that this is not the case with
Squeak's unit tests right now: there are tons of test failures that
are simply known to be failures, so many that you cannot easily tell
when you have broken something new.

I believe that this last problem has had many great solutions
proposed, that we are not using any of them right now, and that we
should adopt one of them.  There is no big fundamental problem!  We
just need to mark which tests are expected to work, and which are not.


-Lex