> Speaking strictly for myself,
> I don't think the out-of-box user experience
> for Squeak should be equivalent to
> the "custom" install of Debian where
> you have to pick from all of those 10000 packages
> the ones you want to load.

    This is not exactly what I meant.

>>     Let the package maintainers take the reponsibility.
>>     (with help from the community).
>>
>>   With proper mechanism, there will be
>> thousands of boxes to pick from.

> I hope so! I, for one, will be providing
> a SM package that will load up
> a Connectors image ready to use for drawing.

    This is more like what I have in mind,
    and don't forget that besides package maintainers
    there are also Squeak educators and authors.
    (there may be even more than maintainers ;)

    Together, they would satisfy almost all needs
    for newbie and 'regular' Squeakers.

    Of course, I wouldn't bother to configure
    an image for Les Trois Croqueteers. ;-)

    Cheers,

    PhiHo.

----- Original Message -----
From: "Ned Konz" <ned at bike-nomad.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, November 13, 2002 9:52 AM
Subject: Re: Testing & Veification of Packages (was RE: Image factoring)


On Wednesday 13 November 2002 06:26 am, PhiHo Hoang wrote:
> > 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'.

I think that's only for the choice of which packages are included in
the distributed images. This assumes that we'd still take the
direction of providing a relatively full-featured image. Speaking
strictly for myself, I don't think the out-of-box user experience for
Squeak should be equivalent to the "custom" install of Debian where
you have to pick from all of those 10000 packages the ones you want
to load.

>     Let the package maintainers take the reponsibility.
>     (with help from the community).
>
>     With proper mechanism, there will be thousands of boxes to pick
> from.

I hope so! I, for one, will be providing a SM package that will load
up a Connectors image ready to use for drawing.

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

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE