Stephen Pair <stephen at pairhome.net> wrote:
[SNIPPED a long description of stuff described many times, thanks
Stephen]
> >The SUnit tests can not replace the knowledge of the authors, and 
> >again this work may have to be done many times instead of once. 
> 
> I don't see where anything has to be done "many times instead of 
> once"...it's simply not the case.

Indeed. The way I want it to work is that the package maintainer adds as
many working configs as he knows about and has the time to test. So for
example, Avi may post 3 different configs for Seaside 4.57 which
described different working conditions (using different versions of
Comanche, etc).

But he can't know it all, and he doesn't have time either. But I may
take the time to try Seaside 4.57 together with another Squeak webserver
that Avi didn't even know about - even though it was on SM.

I may discover it works perfectly and I push a button and publish that
config for Seaside 4.57. The cool part is that not only the maintainer
can publish these. But of course, configs published by the maintainer
may be trusted more.

Anyway, I and many others feel that this plan is simpler, more flexible,
and together with compatlevel should make it very possible to have a
smart engine helping the users and the developers to both resolve
conflicts but also prod maintainers to update their packages so that
conflicts are removed.

And again, not having these puppies inside the packages is obvious to
me. Having it all inside the map will mean that the engine has a solid
domain model to work on. It's all there - right inside the image. And
when problems arise we don't get all these "forced" releases just
because the prereqs were wrong - you can just change them - because they
are not inside the package!

> - Stephen

regards, Göran