> 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".

    I think the 'board' should not worry too much about 'blessing'.

    Let the package maintainers take the reponsibility.
    (with help from the community).

    With proper mechanism, there will be thousands of boxes to pick from.

    Cheers,

    PhiHo.

----- Original Message -----
From: <goran.hultgren at bluefish.se>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, November 12, 2002 8:28 PM
Subject: Re: Testing & Veification of Packages (was RE: Image factoring)


> (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
>
>