Hi all!

Doug Way and I have taken upon us to formulate a plan for 3.6. This
means we are throwing this draft onto you all and we will compile
feedback etc into something we can agree on.

After looking over posts on the subject and chatting with Doug and Craig
on the Squeak IRC channel (yes, don't forget there is a Squeaky channel
available!) we have come down to the following draft plan that is meant
to be kicked around a bit on the list.

The word "Rough" implies that we aren't talking about a strict plan that
we can't change as we go along. But it would still be nice to have
something.

Please be constructive instead of putting it down and please keep all
discussion in this thread - it makes it easier for us to compile. :-)

----
Rough plan for 3.6

1. We are proposing to kick off 3.6 by applying the package removals
currently registered on SM. These will need to be extensively tested
before added to the update stream of course - so this shouldn't hold up
general harvesting - but we still feel it should be done ASAP.

These removals are (descriptions from SM):
	1. BaseImage Tests Removal - This changeset removes all subclasses of
TestCase outside the SUNIT-* categories
	2. Celeste Removal - Refactors mail-handling code and then removes
Celeste references
	3. GamesRemoval - Separates Led* classes into a new category and
prepares to delete the games
	4. MacroBenchmarks removal - removes the macroBenchmarks
	5. PWS Removal - Script that removes the Pluggable Web Server (PWS)
package from Squeak.
	6. SUnit removal - This changeset removes SUnit 3.0
	7. Scamper Removal - Removes Scamper and HTML-parsing stuff
	8. SpeechRemoval - Removes the speech synthesis and face animation
stuff from the image
	9. VM generation removal - change set that remove VM generation related
classes
	10. Ballon3D removal - Removes all of Balloon3D.

I (Goran) have hacked up a trivial load script that performs these in a
working order including installing a few prerequisite packages in the
process. See:
http://map2.squeakfoundation.org/sm/packagebyname/aggregatedremoval

It seems to work pretty ok (and removes about 2Mb netto) but there are a
few small issues and we haven't tested it much at all. This was the
simple step - performing the removals. Now we need to get these things
properly back in! We should at least test installing each one separately
(with prereqs) and all together.

[Area of important discussion: Now - how do we do this in general? This
time perhaps we can muster to test these manually but most logically we
would need corresponding Test packages for each of these packages that
can verify that they are installed properly and that they work - but we
don't have that yet.

Perhaps we should create these 10 testpackages no matter how trivial
they are and then simply say that as long as they are green these
packages are healthy *by definition*. This would also permit us to
construct an autobuilder that installs packages in various combinations
and verifies that they still work.]

When all these 10 removals seem to be working we simply stuff them into
the update stream one by one and either remove them from SM or at least
recategorize them so that they do not apply for 3.6 (could still work in
3.5/3.4/3.2) and then we head for cover. :-)

We also want to give people a chance to produce more removals during the
3.6 cycle but we don't want to hold these 10 up. So we will test these
and get them applied ASAP and then we will take a look on new removals
registered on SM before say 15th June. That is in the middle of the
cycle. So we have until then to produce more removals and they will be
gathered up and applied in a second batch around the end of June.


2. Then when we have a reduced image we move forward with some
aggressive harvesting. Sure, we have performed harvesting during step 1
above - but not "the heavy stuff" since we wanted to concentrate on the
removals. The following areas should probably deserve our *primary
attention* beside the regular harvesting:
	1. Work produced by MCP.
	2. Work produced by KCP.
	3. Anthony's runtime enhancements.
	4. Craig's simulator fixes.
	5. Substantial enhancements currently on SM need to be reviewed and
possibly applied.

Number 5 above refers to packages on SM that essentially are
improvements that could be merged into their appropriate package inside
the image. For example, if there are very nice improvements to Morphic
they could be folded in as long as they don't "produce inter-package
dependencies". Since it will take a long time before Morphic turns into
a real external package we can't keep these on hold. We will compile a
list of the packages that could be considered.

Then of course we have the general harvesting going on. :-) The list
above is so that we do not miss these - it would be harmful to
especially the MCP/KCP projects if their work didn't get the chance.


3. Remove the fonts and replace them with... what? We have had
discussion about using AccuFonts or something else as a better "default"
in the image. More discussion on this please.


4. Move over to SM1.1 which I am working on. This will be an essential
step during 3.6 in order to get package releases and a proper package
cache. Since 3.6 is the first release really relying on SM we simply
can't do without versions of packages, which is in the brewing SM1.1. We
also would like to be able to rely on a proper package cache since this
would open up nicer options in how we deliver Squeak, see below for some
ideas. The move shouldn't be necessary early in the cycle - just as long
as we do it before 3.6 turns official. And of course the sooner the
better. :-)

Packaging

Squeak 3.6 will could be packaged slightly different. One rather nice
way would be to package in two different zip-files:
	1. Basic image + subset of SqueakMap package cache suitable to reach a
Full image. This gives the user both the Basic image and the ability to
easily load a loadscript to reach the Full image.
	2. Basic image + a full SqueakMap package cache. This gives the user
all packages available on SqueakMap in one big Zip.

Obviously the package cache would also include the load script to
produce the Full image and perhaps even have it as a clickable link in a
Readme or something. We could also revise the SM "bootstrap" to be less
"chatty" I think.


After 3.6

After discussing with Craig Latta we came to the conclusion that his
work (Squat) to reach a Minimal kernel image etc should wait until the
version following 3.6 - which could be version 4.0. The VI4 changes are
also scheduled for a later version, typically version 4.0 since it is a
big change making images barckwards incompatible.

We also postponed deeper digging into ripping apart Sockets/Streams etc
since that work is done by Craig in the Squat project anyway. This means
that 3.6 will not reach the "Minimal" image but instead take a hefty
step towards "Basic" - that will probably be good enough and set the
stage for 4.0 and the merge with work done in Squat.

But do note that we haven't decided that 4.0 is the version following
immediately after 3.6. But we should consider it.

Ok, let's keep the discussion fruitful!

regards, Göran & Doug