squeak releases, now and in the future

Matthew Fulmer tapplek at gmail.com
Mon Jan 21 22:41:15 UTC 2008

The release team has struggled for two releases, as more and
more forks of squeak emerge and gain relevance. If any lesson
has been learned, it is that the tools to build a single release
image do not work the same when applied to the very forked world
that squeak is and is becoming.

On Mon, Jan 21, 2008 at 05:00:41PM +0000, Keith Hodges wrote:
> Jerome Peace wrote:
> > Hi all,
> >
> > I think we are at the anniversary of the start of the
> > six month timebox for 3dot10.
> >
> > I am watching a lot of interesting developments.
> > Damiens efforts seem to have become squeak's flagship.
> > And VPRI has found resources and interest in
> > developing 
> > squeaklands branch of 3.8 and OPLC.
> >
> > As for our squeak-org branch, it seems to me the basic
> > maintenence and releases of squeak are in neglect.
> >   
> I do not entirely agree with this conclusion since there is work taking
> place in this arena.

Also, don't forget that 3.10 was entirely a bug-fix/maintenance

> The LevelPlayingField initiative is aiming to provide a
> platform/framework whereby we can care for all of the squeak.org
> releases that we use. This also provides one framework for integrating
> portions of work towards future releases.
> Within LevelPlayingField there are spaces for several projects that will
> contribute to a future release, and so really there is no stagnation at
> all, and there is plenty of room for many others to contribute.

I think the big goal for 3.11 should be to embrace what squeak
is (a community of cooperating system forks, exploring many
fronts at once), and not what other projects may be (a
single-mission project with a well-defined audience). This
exactly the spirit that is driving Level Playing Field and Delta
Streams. Level Playing Field has been in development for two
years and is ready for prime-time. Delta Streams is still is
alpha stage.

Is  Squeak a  production-ready stable platform for developing
large services? Yes! Is Squeak a platform for children to
experiment with? Yes! Is Squeak malleable playground for
researchers to implement the coolest developer tools? Yes!
Should the release team focus on one facet at the expense of the
others? No!

Forks can have drawbacks when the tools or politics stifle
communication and trade between the forks. Unlike many projects,
Squeak does not have political or social barriers to stifle
trade among forks of the system, but the tools for building and
maintaining images (Monticello and the update stream) have
barriers that dull their edges when applied to multiple forks.
Update streams are a wonderful tool for building and upgrading
images, but were built back when squeak was a Monarchy (Long
live king Dan!) and does not deal at all with either multiple
update sources or with incompatible recipient images. Delta
Streams address these problems and more.

Monticello is great for sharing code among everybody, but has a
sore spot when the receiver or loader is not what is expected.
Level Playing Field addresses these system nuances so that a
target system is much more likely able to properly load a
package built for another system.

And the newest tool, Installer, is able to apply the work that
code developers have already done in packaging up their projects
in easily installable forms (whether it be SqueakSource,
SqueakMap, Universes, change sets, packages, or whatever), and
in a single line of code make it into an installation
script.This will take the very boring, non-productive job of
repackaging code for a specific fork away from the release team,
and make the job of coordinating developers with release goals
both easier and, most importantly, more FUN.

> > My druthers are that time boxes get honored. That
> >   
> I myself am not such a stickler for timeboxes, I think you
> could effectively time box bug-fix releases. I do believe that
> improvements in tools will make everything a lot easier. The
> tools that need improvement are not part of the squeak
> kernel/core so it is not surprising that the kernel is not
> being looked after as perhaps it might be until those tools
> are complete.

Squeak is NOT an application that you download, use, and
upgrade. It is much more like a community portal to lots of
people, ideas, tools, and code made available to you for your use
and enjoyment. I think it should therefore have more of a
service-type release process (we have many different varieties
to suite your needs, and we have them all working and up to
date; and there is a special  going on with this one right now),
rather than the ill-fitting application-style release process
used currently (This specific fork is the real deal; all those
others are handled by someone else (who often never exists)).

Once DeltaStreams is working, applicable bug-fixes and
zero-impact changes (like all-important Code-Comments) will be
distributed ed on a push basis with automatic background
installation and upgrade, or at most a single-button push to
"review and install subscribed updates". And, thanks to
Installer, this could be run once-a-week on the images at
ftp.squeak.org as a Cron job to ensure that the official
images are in pristine shape on download.

> I then propose that the "official" release team be comprised
> of people who have been taking an active role in the process,
> and who use #squeak irc communications regularly so as to
> encourage many more contributors and to faclitate online
> teamwork. Gjallar has used this model reasonably successfully.

I definitely think that this is a much better team model than 3.10 had
(which was mostly done behind closed doors). #squeak IRC channel
is a pretty active place, and all manners of viewpoints are
readily available there. Quite a few bugs get discussed and
fixed there, since feedback is so fast.

The release team has taken large steps toward modularity and a
many-faceted Squeak world with the switch to Monticello, and has
learned a lot in the process, and had many headaches. It is now
time to take a hint from the lessons learned, and chase down the
headaches that still remain, and stop them at the source:
ill-fitting tools.

Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

More information about the Squeak-dev mailing list