I just rolled an image to 3.4a and noticed that YAXO is now in the
stream...why?  Aren't we trying to make things more modular and move away
from the kitchen sink image approach?  This would seem to work against that
direction.

Why not start a SqC Squeak distribution that has its own set of packages
pre-loaded and keep the contents of update stream to a minimum?  (in fact,
maybe we should make a rule that change sets in the update stream should
yield a net reduction of the code base in the base squeak image)...ok, I'm
exaggerating a bit here, but is the idea valid?

I imagine if you started packaging things like YAXO into SARs (with a change
set and DVS package), then you could quickly qet to an automated build
process where you take a fully up to date image and load the various
packages for the SqC distribution...and perhaps do it nightly.  The only
issue then is versioning the packages (which I think we could use my
VersionNumber (http://minnow.cc.gatech.edu/squeak/2511) stuff to give
package file names a version number...this could be optional with DVS if you
want to use a version naming conventiong instead of CVS...it would allow you
to handle the case where two people concurrently work on version 1 of a
package and both try to file out their changes (the first one to file out
would be "packageXYZ-2.st" and the second would be "packageXYZ-1.1.st").
Merge tools could be added at a later date.

VersionNumber and VersionHistory would allow a build script to say "give me
the latest mainline version of packageXYZ" (VersionHistory can be inferred
from a simple directory listing of everything matching "packageXYZ-*.st").
You then just ask your VersionHistory instance for the latest mainline
version.

So, I see 3 simple additions to DVS that might be useful...

	a) allow a change set to be added as a preload to a package (for changes to
external packages to be separated from things that actually belong in the
package)
	b) have DVS use the SAR format for externalizing packages (so that the
change set and *.st file can be maintained together)
	c) have DVS incorporate VersionNumber (and show the version number in the
package browser) as an optional way of naming packages and thus keeping
version history

A nightly build script could then simply say: take the latest image, load
the latest versions of packages A, B, and C, load and execute SUnit
packages, and if everything looks good, save the image to an ftp download
site.

- Stephen