Boosting Squeak: RockSolid images

As some of you know, I was a Smalltalk fan&developer in the last twelve years. I have stopped working on smalltalk years ago... anyway, I am happy to look forward the Squeak Smalltalk Community from time to time.

I republish here an original article posted by me on SqueakPeople, over 4 years ago. The reason is simple: I am very happy to see a Squeak code fork called "Sapphire" which share most of my thoughts:

Sapphire wants to take a fresh look at the Smalltalk philosophy and current implementations. The idea is to produce high quality open-source packages that will be loadable on a micro kernel. 

 I will take a look to Sapphire, and you will find my throughts here in the next months.

Boosting Squeak: RockSolid images Posted 30 Dec 2004 by jj (Journeyer)

I have read the "rant" and "unrant" subject with a mix of uneasiness (embarrassment) and fear. The "Rant" thread began on the 15th of December 2004, and produced a lot of discussion. I will not summarize the thread, because a lot of people read it. Instead, I will go forward and try to find a pragmatic and constructive of helping the community (and yes, I am also very bold and handosome :) << ironic comment).

Part I: The "easy smalltalk"

I think the true problem faced by squeak is to boost harvesting and organize things so that the real problem will be the opposite: too many people fixing bugs :) The stronger danger is the feel of unstablility of squeak; I got some problems when trying to develop a small project in my spare time, forced not to update to the latest squeak because of incompatibilities and so on. On the opposite, mantaining Celeste requires me to be always up to date, and I will not be shocked if the beta release is a bit unstable: I need it!

So my needs change in respect of what I am doing.

On the other side, developing with a stable system is a pre-condition to leverage the community and helping the widley use of squeak in big project. In my opinion, if squeak users feel unstability as a problem, we will never go on without solving it. Decoupling the core release schedule from package release schedules would allow the package maintainers to work at their own pace. This is more or less how it is today. Though perhaps not clearly stated.

We must enforce all these ideas, so I have this proposal: We can have a very dynamic, and tiny "Base Squeak Image". It will be depurated from all the libs with the exclusion of

   Kernel/Collections and so on   VMRebuilding (needed to generate the SqueakVM)   Mophic   Minimal Sound Support   Minimal Networking Support (only for updating it...)

The base image should be "naked" and only for developers: they can choose the tools to configure it. This could be the goal, the essence of the "Base Squeak Image": light as a mouse, strong as a tiger :)

Then we can have a "Rock Solid" released about every two or four base Squeak releases. It will have a new version number but the "RS" letters at the end. For example:

 

  Squeak 4.0 RS  Squeak 4.1 (base)  Squeak 4.2 RS  Squeak 4.3 (base)  Squeak 4.4 (base)    Squeak 4.5 RS      <--- Example of delayed Rock Solid release

(Note: there will never be two release with the SAME number, to avoid confusion) The RS should have: a Release notes Workspace and some nice stuff for developing already installed. They will be very very similar to the current releases, at least with some more toys (like Celeste...).

Part II: How will we do it? The incremental step!!

I love the Part I because all seem easy: the trobule went when we JUST try to DO IT.

To obtain a such thing we need to restructure the actual community, and also to change our way of thinking squeaking? Someone said we have tons of things to get a grip on but we are more or less paralyzed unless we change the way the community is "steered".

The Guides approach may need re-targeting and recalibration, but I will not face this problem now.

The process which brings us to the RockSolid idea will be incremental: let's start with the actual base image, and start building the first Rock Solid on it.

We can have a Linus-like leader (RockSolid Man or R-Man :) which will do this hard job, asking support to Guides, for example.

We can choose a new R-Man for every RockSolid release, thous freeing it to have too much work on his/her shoulders.

A similar approach will bring to us a more clean evidence of problems, like abandoned code, lazy supporters, alone girls asking for an hero saving them and so on.

On the other side this approach will slow down things at minimum and reduce the "friendliness" of the community of a very very small portion. The squeak-dev mailinglist will have only a new [RS] tag on it.

In summary we have:

• Goran Bi-Weekley report: http://anakin.bluefish.se/gohu/30
• KenCausey proposed voting system on Squeak people With about 200 registered users on squeakpeople, we can have a good direction.

We need:

1. R-Mans
2. A bunch of SUnits code to build the RockSolid Image. This code will help us to speedup the process.
3. Voting the above ideas.

The good (?) news is: I will give my work to let the thing born. I will help for emerging of a more vast and accepted way of organizing this thing. I know Squeak, the base kernel, and the collections (and my Italian DNA give me also a lot of good advantages with "alone girls" :)

If you like I can also be the first R-Man (it look like a very bold and handsome position :) << ironic comment).