Testing & Veification of Packages (was RE: Image factoring)

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Wed Nov 13 01:28:19 UTC 2002


(damn is the list active now...)

Ned Konz <ned at bike-nomad.com> wrote:
> On Tuesday 12 November 2002 04:52 pm, Swan, Dean wrote:
> 
> > I really like the direction that the image factoring/modularization
> > work is currently going (as in SM and DVS), but I also really like
> > that an "official release" image of Squeak like 3.2-4956 has been
> > fairly well excercised as a whole, and can be trusted as fairly
> > stable and reliable "right-out-of-the-box".

Actually, I think we can get best of both.

> > I'm not too excited about the idea of having to take an "official
> > release" of the Squeak kernel and add packages in my own unique
> > combination to get the image I want then have to spend lots of time
> > verifying my newly constructed image.
> 
> I think that (as Michael said) we can have the best of both worlds if 
> we have "release testing" and provide different flavors of 
> pre-packaged, pre-tested images (or scripts that will construct them 
> easily).

Exactly. In the next major release of SM I want to introduce "package
releases", "package configurations" and "image configurations". The last
one is exactly such a script that takes a base image and then installs
package releases (specific versions that is) in a defined order. This
will ensure that the end result is the determined.

Then, typically - we will have "image configurations" as releases
instead. And then it is just a matter of how the community will handle
this freedom. Typically I would guess that we try to do releases by
simple picking the current base image (they should always be stable) and
then add a bunch of "blessed" packages on top that we consider to be the
most important base packages with releases that are classified as
"stable".

If we don't do this release procedure too often then those image
configurations will be fairly well exercised as a whole etc. This is by
the way very similar to how it works in Debian. And Debian is ROCK
SOLID. And they have 10000 packages with 1000 package maintainers -
so... it can be done. :-)

> That said, I rather like the new CPANPlus functionality that the Perl 
> community has: if you load a module from CPAN that has unit tests, 
> the tests are run. If the tests fail, CPANPlus asks if you want to 
> send bug reports to CPAN (or somewhere; I'm not sure where they go). 
> If you agree, the bug reports are both stored on a server, available 
> via a web interface, and sent via email to the maintainer.
> 
> As a CPAN author, these reports have been helpful from time to time in 
> detecting problems common to a particular configuration.
> 
> I'd like to see this (optional) ability for those packages that 
> provide tests. And I'd encourage package maintainers/authors to 
> actually write tests (not that I have any for my packages, of 
> course...)

I agree this would be very nice - Michael has also mailed me about this.
The SSTCPW is probably to just add another url called "Download tests
url" or something. Optional of course.

regards, Göran




More information about the Squeak-dev mailing list