Image factoring

Göran Hultgren goran.hultgren at bluefish.se
Tue Nov 12 19:48:23 UTC 2002


Quoting Tim Rowledge <tim at sumeru.stanford.edu>:
> "Norton, Chris" <chrisn at Kronos.com> is claimed by the authorities to
> have written:
> 
> > [ snip Colin's interesting discussion of splitting PWS from Squeak ]
> > 
> > You raise a bunch of good points, Colin.  But one thing that concerns
> me,
> > even more than *who* maintains a package, is that there is no *proof*
> that a
> > package will work, once you get it back into your image.
> 
> An excellent point, and in fact one of the issues that makes it so much
> simpler to go with a monolithic image - if it isn't there, it doesn't
> get tested even minimally. We have to find a way to get beyond this if
> a chunked out system is to work.
> 
> As a minimal start I'd suggest that the info on SM should include two
> (hopefully) simple details - the _earliest_ release it has been tested
> under and the _latest_. Either can be updated whenever it can be shown
> to be appropriate. This should at least provide some confidence when
> loading into one of the systems between those two numbers. We ought to
> be able to make the package lister/loader do the version number testing
> automagically, surely. Maybe the listing for 'obsolete' packages should
> be in some ugly colour to drive the point home.

Ok - but this still only works when a package only depends on the base image
version! And that is soon going to change drastically - when more and more gets
broken out of the image more and more packages will start depending on other
packages.

My proposal is something similar but a tad more advanced. In 1.1 of SM (next
will be 1.01 with minor fixes) I want to introduce the concept of a "package
configuration" which is simply a list of "package releases" that the package in
question has been verified to work with and a name+email of the person
registering it.

Typically the maintainer of a package would register at least one working
package configuration. But other developers might register other configurations
that they have concluded work. So comparing this approach with for example the
Debian system the package config is not "included" in the package, which means
we can have several of them and not only the maintainer can register them. I
also note that a package configuration makes no guessing like "version >=1.01 of
package X". It simply states the exact release that it was tested against.

More on this in another post about the "SM roadmap" - there are some other
mechanisms that I would like us to use together with this.

> It really does emphasize yet again that people providing packages will
> need to do some extra work (I call it 'engineering' :-) ) to provide
> some tests and to keep things up to date. Or, of course, find
> assistants
> to help from the wider community.
> 
> I think this represents a good opportunity for squeakers with limited
> time (or
> experience) to both contribute and learn, by signing up to do a test
> load and run of a package each time a new base image is released. It's

Yes.

> important to have somebody _not_ intimately familiar try this since we
> rarely see anything other than what we expect. At ParcPlace we used to
> call this MATing season (for Minimal Acceptance Testing) and the
> screams
> of terror as vm weenies had to try to install database drivers or use
> those wierd application drawing tools were truly heart-rending. But not
> as much as those from the database dweebs trying to compile a userprims
> VM :-)
> 
> tim

regards, Göran

Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek



More information about the Squeak-dev mailing list