Hi people!

The question from Brad Fuller (below) spurred me into doing a recap of
how Squeak is ... well, partitioned or whatever you call it. This is
good to know - and not really dead simple, so I will give it a shot to
explain. 

Doug Way <dway at mailcan.com> wrote:
> On Jul 11, 2004, at 2:47 PM, Brad Fuller wrote:
> > Hi all,
> >
> > What is the criteria and approval process of being in the base image?
> 
> The approval process (Harvesting Process) is pretty much covered here:
> 
> http://minnow.cc.gatech.edu/squeak/3152
> 
> Note that there aren't really strictly defined criteria for something 
> to be allowed in the base image, other than approval/review from one or 
> more harvesters and other volunteers.  However, most of the things 
> being discussed here (Squeak Server Pages, EventRecorderMorph, etc) 
> pre-date the existence of the Harvesting Process anyway. (they were 
> added earlier in the days of Squeak Central)
>
> - Doug

Doug refers to how code changes (additions/removals/modifications) to
the classes LIVING in the current Basic image are handled. In short it
goes like this:

	1. Someone makes a nice FIX or ENH (enhancement) to the image and sends
it to the list, preferrably using the ChangeSorter tools in the .cs.gz
format - a compressed ChangeSet. A ChangeSet is like a "tape recording"
when the user did his/her modifications. Those are very nice for these
things.

	2. The ChangeSet gets sucked up into what we call BFAV - Bug Fixes
Archive (Viewer). BFAV is like an assembly line where these FIXes get
collected and then go through a few different states. Anyone can install
"BFAV2 Installer" (that is the one you want, NOT any other package) but
you need to use Squeak 3.7b. It is also a very nice tool to give
feedback and reviews on FIXes and YOU can play a vital part here, even
if you don't know how to code.

	3. Eventually these changesets gets rejected or approved, but only the
Harvesters can approve. When a changeset has been approved it sits there
and waits to go out as an update. Doug is the update master - he will
collect them, make a final test and then shoot them out. These you can
load into your image by pulling out the left flap and push "Load code
updates".
 

So the above process covers most of the stuff in a Basic image. The
Basic image is the image that is fed the update stream. The latest at
the moment of writing - the bleeding edge - is 3.76beta-5969, available
here:

	ftp://st.cs.uiuc.edu/Smalltalk/Squeak/3.7beta/
(well, 5967 is the latest zipped up, just load code updates to get the
last two)

Ok, BUT... the above describes how you get modifications of the stuff
that lives IN THE IMAGE into the image. But the Basic image also
contains stuff that doesn't LIVE there - it contains a few loaded
Packages.

If you start a fresh 3.7beta Basic image, open the Package Loader,
select "only display installed packages", then you will see that it
contains these packages:

Compiler (1)
MCInstaller (8->10)
PackageInfo (16)
SARInstaller for 3.6 (28)
SUnit (3.1.6)
SmaCC Smalltalk Compiler-Compiler-Runtime (2)
SqueakMap2 base (0.96->1.0)
SqueakMap2 loader (0.92->1.0)
VersionNumber (1.0)

(sidenote: If we look at
http://map1.squeakfoundation.org/sm/category/af36d60e-6066-4d68-bae0-90c
459f5b9d8 then we see that this information is not accurately
represented in SqueakMap. But the current categorization scheme is a bit
messed up, so we can wait a bit until I get things straightened out both
UI-wise and a few extra mechanisms are needed)

Now, these packages live their own lives with their own update cycles
and their own releases. And their own dedicated maintainers. The version
installed in the image is shown in parenthesis, if there is an arrow it
means that there is a newer release available to install.

So... how did those packages end up in Basic? Well, we have decided
together that they need to be there. :) We are working slowly towards a
Squeak which is more and more partitioned in packages.

Putting a package into the package group "Official package in Basic"
means that we decide together that it is needed, and the maintainer is
willing. Then we simply issue an update into the stream that installs a
specific release of the package using SqueakMap.

So "being in the image" can mean two things:

	1. Code that has gone through the harvesting process and entered the
image as a changeset through the update stream. That code is truly in
the IMAGE and it will evolve further using the harvesting process. There
is no special maintainer for that code - we all maintain it together.

	2. A package that we have decided to load into the image using
SqueakMap. A small update is sent out that simply has a command that
installs the package using SM. Such a package is "more important" than
other packages and we need to make sure it works properly etc. But it is
still a package that has a maintainer and a release cycle independent of
the update stream. Normally the releases are somewhat coordinated with
the releases of Squeak. For example, I am currently furiously trying to
shape up the SqueakMap2 packages in time for the Grand Release of Squeak
3.7! :)


Finally it is worth mentioning the Full image. The Full image is the
Basic image with more cool packages installed on top. When the Basic
image is getting ready for release - like NOW - the assembly of the Full
image needs to be taken care of. It results in a load script:

	http://map1.squeakfoundation.org/sm/package/412ecc69-eeda-4029-8113-27c
e05bdc7c0

That when installed into a Basic image will install a whole bunch of
other cool stuff on top.


Well enough for now, hopefully someone learned something new. :)

regards, Göran