Hi Martin,

> >> And if it is not in the image, it is not being used and so it will 
> >> not get tested. That would be a big change in practice.

I think your argumentation is slightly off here. Let me try to point out why
I think having "full" images and update streams is advantageous for
development: It is awareness and ease of change. What this means is that if
a package is present you are immediately aware of potential problems with
that package when you modify something. When it is at SM you don't. So you
change things, and then some package maintainer has to (more or less)
reverse engineer your changes in order to figure out how things ought to
work according to your new rules.

An excellent illustration for this problem is Anthony's rework of the EH
stuff. In its original form, it contained a number of fixes to various
exception classes, including TestFailure. The fixes for TestFailure, due to
being part of the (at that time non-basic) SUnit package were removed before
the changes went into the update stream. As of today, SUnit is still broken
in exactly these places. It is not that Anthony didn't fix them (he did) it
is that the mere act of separating "cause and cure" of a problem introduces
a significant additional barrier.

That is the real problem we're talking about - the difficulties to detect
dependencies in external code, the disproportional amount it takes someone
to fix a problem that someone else introduced, the (very realistic) chance
that a package maintainer overlooks a problem that is introduced by a change
done by or in some other package, the inability for someone who does a
change to ensure that even required fixes really make it into the
appropriate packages. Note that for the person doing the change in the first
place, these issues are typically trivial to fix (again, see the TestFailure
example, and the same can be said about things like KCP or MCP) but it is
very hard to find and fix them if you are not the person who has done those
changes in the first place.

By the end of the day, this is the same line of argumentation that has been
made various times about "code rot" when certain changes don't get in the
image soon. It is caused by people (note: people not tools!) simply not
being aware about dependencies, it is caused by even if you try your best
and fix every last place it doesn't mean you can ensure that your fixes
reach the intended audience.

Of course, that is noones fault - it is a mere matter of fact. That's why I
think that it makes sense for all "general" Squeak development to use full
(or more) instead of basic images. Not because of testing (since here I
agree that presence of a package has very little to do with it) but rather
for being able to rapidly detect and cure problems you have introduced
during development.

Cheers,
  - Andreas