Alternative approaches to the development of Squeak
Last updated at 6:18 pm UTC on 14 March 2007
The processes of development of Squeak have gone through some changes and have seen some proposals, so in the context of writing a bit about the latest experiment along this line, here's some summary/history with links.
In the beginning, Squeak was a closed project at Apple. Then it was released as open source, and quite quickly, people started posting improvements, such as Ian's port. At some point, the Update Stream was created. The basic idea is that change sets gathered by SqC from their own work and from the community were numbered and put up in a central server, such that they can be loaded in order from oldest not-yet-loaded to newest from a menu item in the image.
In version 3.3 an attempt was made to create and adopt a Modules system that would make code management in many ways. Some of the goals were:
- Divide the image into parts with well defined dependencies
- Version such modules
- Load such versions from the web
- Make the modules have separate namespaces
This experiment didn't take, its abandonment is explained here Dan Ingalls on where Squeak is headed, along with some ideas at that time on how to proceed.
One conclusion was that the project had tried to solve too many problems at once, making too many incompatible changes to the way things are done.
Another project with different philosophy but related goals (including 1,2,3 from the above) is described at http://swiki.squeakfoundation.org/stablesqueak.
Quite soon after the formal demise of 3.3a modules, the SqueakMap project became functional, focusing on allowing people to easily install code published independently.
This also changes the nature of the problem: before SqueakMap the update stream was almost the only way Squeak related software was widely distributed. With it, the image becomes a way of delivering packaged functionality, growing parts of which are maintained as packages on SM. Therefore the update stream becomes a way to maintain the (slowly) shrinking portion of the image that cannot be maintained so.
Looking at how the work of gathering changesets for the update stream happens, at some point, people volunteered to help SqC with this "harvesting" process. This happened using the Bug Fixes Archive.
When, as described in DanI message linked above, control of the update stream passed to The Guides (towards the end of the 3.4 release), a more decentralized group, this process turned out to be very inefficient, a situation which was greatly improved by the introduction over time of a few rules (see Harvesting Process) and better tools, specifically the (obsolete) BFAV.
Remaining problems and future ideas:
- We don't have a bug/issue tracking process. Existing tools don't really aid it, and we're trying out an open source tool (non Squeak based) called Mantis for it. Its at http://bugs.squeak.org/ .
- Even with better tools and some rules, while the process now allows the harvesting to go about as fast as it ever went, there are consistent grumbles that it is too slow and requires to many interactions. One solution that is being tried out in the 3.8 alpha stage is to have an unstable update stream.
- Another problem is that there exists an "impedance mismatch" between the update stream technology itself and the view of Squeak code as managed in Packages, of which versions are published. This view of code is now becoming more important with the increasing use of SM, Monticello and SqueakSource. This problem and the previous one are the targets in another experiment called Alternative approaches to the development of Squeak.