[Squeakfoundation]base image distribution

Daniel Vainsencher squeakfoundation@lists.squeakfoundation.org
Mon, 09 Dec 2002 17:39:11 +0300


The directions you are talking about are not theoretical, that's where
it's going. In order for the process to work though, we have to work
within some constraints:

1. People contribute to Squeak because they can run it and play with it,
and modify it, and on it, they also get all this cool Stuff. Therefore,
SqueakMap comes before any stripping. StableSqueak ignored this
constraint, and that alone was a big risk. We're past that step.
2. People want to run some complicated things that require lots of
infrastructure, like Celeste (HTML, networking, MailMessage, Morphic,
FileSystem...). We are not the Forth crowd, where users are happy if
they get multiplication of Floats in the library (just kidding!).
Therefore, no serious stripping before we get some working mechanism for
distributions/configurations. 
3. While we work to make Squeak more malleable to more people, we need
to make sure we don't turn it into putty nobody can build anything on.
If there is no mail client in Squeak, just in SM, that's fine. If
there's no one socket api to work against, we have a serious problem.

Stephen, I think people starting to build their own images from base +
packages could be a great accelerator for all the reasons you mention.
After we get configurations, this work will be easily sharable, too.

Do you want to try it out and publish your process so people can repeat
it and improve on it?

Daniel

Rob Withers <rwithers12@attbi.com> wrote:
> I completely agree, almost.  :)   What is the smallest feature set for the
> base stripped image?  Is there a swiki page on this?

> cheers,
> rob

And  
> From: "Stephen Pair" <spair@acm.org>
> Indeed, I'd take it a step further and say no new features period...ever
> (for the base Squeak that is).  Stuff like a new events mechanism,
> networking frameworks, etc...should all remain as external packages.  We
> need to be working in that opposite direction and start having change
> sets in the update stream jettison code, not add.
> 
> Now, what would be great is to have a base Squeak realease, plus a
> number of "distributions" that contain a variety of packages that are
> pre-loaded.  One of these could be the SqC distribution that is
> downloadable from the squeak.org site (this would be the distro that
> most people download first).
> 
> One of the things that could be done to help encourage progress in that
> direction is to start thinking about automating image construction
> (i.e., take the base image, add packages X, Y, and Z, then publish
> somewhere).  Some tools to help with that would be nice.
> 
> - Stephen
> 


Stephen Pair <spair@acm.org> wrote:
> What I would suggest (and I'm probably going to start doing this at some
> point in the future myself) is that you (and others) start publishing
> your own Squeak image...and do it through an automated nightly job that
> pull the updates off the stream, collects all of the packages that you
> want in the image, runs any Sunits, etc.
> 
> This will be useful in a number of ways:
> 
> 	a) it will serve you by having an image readily available with
> exactly the things you want in it
> 	b) it will serve the community by making that available
> 	c) it will keep you disciplined in the sense that any changes
> you want included in your base image will be factored out and separately
> loadable
> 	d) it will serve the community because it will be exercising a
> lot of code (and probably Sunits) on a daily basis (if anything breaks
> in your build, we'll all know right away)
> 	e) it will serve you because if anything does break your build,
> you can point to exactly what change caused it to break, alert the
> people involved, and get them to change their code to accommodate your
> build
> 
> The thing missing here is the automated part...but that can come with
> time.
> 
> - Stephen