Final 3.6 Plan

Stephane Ducasse ducasse at iam.unibe.ch
Wed May 14 07:44:10 UTC 2003


Hi doug and goran

Good work.

I imagine that we may introduce some simple bug during the process but 
we should not worry too much because
after we will fix them. I think that we should use more alpha as a 
place where things can move and be changed.
It is better to go fast even break ing and bit and repairing than 
slowly.

For the image: why not one image full + script to unload.

Stef


On Wednesday, May 14, 2003, at 08:13 AM, Doug Way wrote:

>
> 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