Final 3.6 Plan

Doug Way dway at riskmetrics.com
Wed May 14 06:13:05 UTC 2003


Goran and I recently realized that the "draft" 3.6 plan which we posted 
to the
list a month ago was never declared as "final".  At the time, there was 
some
discussion of the draft plan, but no major disagreements, so we've been
proceeding with the plan anyway, more or less.  But we should really 
declare
the plan as final so that there's some understanding in the community of
what's going on.

So, I've compiled some of the feedback, added a few of my own items, 
cleaned
it up a bit, and attached it to this message as the "final" plan for 
3.6.  (I
suppose this should be posted to the Swiki.)

Some additional comments, followed by the plan...

- [Harvesting has stalled recently]
   Harvesting has stalled a bit recently because of a couple of things, 
I think... Mostly, we probably just need more harvesters.  I'll be 
sending out a request to the list soon about this.  But also, I think 
there's been some uncertainty about what sort of harvesting (if any) 
should be going on while we're adding these larger items in the plan 
such as the removals and the KCP/MCP projects... this has probably 
hampered harvesting a bit too.

   For now, I'd recommend that we incorporate the KCP & MCP stuff soon, 
one after the other, and then after that all other enhancements and 
fixes can be harvested "in parallel".  KCP & MCP are both group 
projects, which differentiates them somewhat from all of the other 
largish enhancements being proposed, so in that sense perhaps they 
deserve the luxury of being added "serially", without worrying about 
other stuff be added at the same time.  Plus they're more sweeping 
changes than something like TrueTypeTextStyle.

   We can use the current harvesting process for all of these other 
enhancements, even if some of them are "approved" ahead of time via a 
SqF list discussion or whatever informal process occurs... just to help 
with tracking them.  (The current harvesting process (as defined on the 
swiki) is actually quite simple... a [FIX] or [ENH]ancement is posted 
on the list here, and then if a harvester [approve]s it, it gets 
incorporated a few days later.  That's it.  Other people can contribute 
by adding tags etc., but these are not required, they're just helpful.)

- [KCP/MCP status]
   The approved KCP items will be incorporated very soon, hopefully 
tomorrow.
The MCP stuff has also been approved, and so it could be added soon 
afterward,
although someone will need to check for conflicts with the removals and 
also
the KCP items.  We should try to get the MCP stuff incorporated within 
a few
days of the KCP stuff, so that we can proceed with everything else.

- [Other issues such as clarifying the Guides' "vision", and a new 
process for
PROPosals, licensing]
   These issues will be worked on, but aren't tied directly to the 3.6 
release
plan.  Clarifying the vision is a more long-term issue, for example.
Licensing is another long-term issue which shouldn't be ignored, but is 
not
tied directly to the 3.6 plan either.  (Except for the fact that we 
wanted to
remove the Apple fonts in 3.6 in order to be able to move ahead with 
licensing
issues.)

- [Next version]
   The next version could be 3.7 or 4.0 (image format change), haven't 
decided.
There was some discussion on this in the "Draft rough plan for 3.6" 
thread,
but it was unresolved.  Also adding Anthony's blockclosures & new 
compiler to
3.6 are related issues.  From re-reading the thread, I'm under the 
impression
that we'd like to at least add blockclosures soon, plus some simple
non-image-format-changing changes (e.g. context caching) so that we 
don't lose
~15% performance from adding blockclosures.



------------
Plan for 3.6

1. We are proposing to kick off 3.6 by applying the package removals
currently registered on SM.  (As of 5/13/03 this is now done, except 
for #8,
see below.)

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.  (This one was not removed because re-adding the 
package
resulted in errors.)
	9. VM generation removal - change set that remove VM generation related
classes
	10. Balloon3D removal - Removes all of Balloon3D.

[Test packages - Doug]
   We still need to have corresponding Test packages created for some of 
the
removed packages.  Marcus and I will probably have to bug the 
appropriate
package owners to create these.  We should have these in place before 
3.6 goes
final, so that all "Squeak Official" packages have corresponding Test
packages, and that new package removals won't be considered unless a 
Test
package is in place.


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.  (Including Michael's networking rewrite, 
TrueTypeTextStyle,
etc.)

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". (Some inter-package dependencies will be normal.  The
main point is that the package should be reasonably easy to remove again
later.) 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 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.

[Providing a Full image with the release - Additional notes from Doug]
   In addition to the current 3.6 Basic image, the Full image
functionality will also be made easily available as part of the final 
3.6
release.  But we still haven't decided whether we will provide it as a 
second
image to download, or whether it will only be provided as a one-click
bootstrap sort of thing from the Basic 3.6 image.  I know Goran has 
mentioned
that having a one-image release (w/bootstrap) would be simpler, but I 
think
I'm still leaning toward having two separate images (both available on
squeak.org) as the release.  Either way would probably work, though.  
Ned is
working on a removal/addition package for the demo "Worlds of Squeak"
projects.


[Release dates - Doug]
   The release date for 3.6 final is August 1st, in keeping with the 
4-month release cycle idea, and the first-Friday release date within 
the month.  Beta/Gamma dates haven't been discussed, but I would 
propose having the gamma release 2 weeks before final, and the beta 4 
weeks before the gamma.  (If a big problem comes up during gamma, the 
release would be postponed by 2 weeks.)


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.

regards, Göran & Doug



More information about the Squeak-dev mailing list