On 13.04.2010, at 16:59, Chris Muller wrote:
> 
>> There is one fundamental problem with both the SqueakMap and Universes model that has not been mentioned yet: It does not encourage participation.  For a package author, maintaining a package entry is just an additional burden. And a package user cannot really do much about a broken package entry.
>> 
>> Contrast that with the Trunk Model: One reason it works is that it takes almost zero effort to participate. You publish a fix to the inbox and announce that on squeak-dev. And it's very simple for a core developer to take it and commit to the trunk.
> 
> These statements are true, but based on the premise that the goal is
> to "participate".  For "participation",
> as you said, we already have the trunk process, therefore, I don't
> think SM needs to try to duplicate the fulfillment of that role
> because the goal of SM isn't to offer the "latest and greatest" of
> every package.  Instead, I think SM can fill a gap in the area of
> documentation and exploration.
> 
> How does the trunk process let me explore MorphicWrappers?  Answer:
> it doesn't.  SqueakMap does, because all of the older Squeak images
> are available, and since SM documents which image version each package
> is for, it provides an avenue for quickly exploring an older package
> that *works* in the image it says it works in.

But how do we make the SM entries for a particular package and a particular Squeak version? *That* is where I see the bottleneck.

Someone who figures out a load procedure because they need a certain package in their image, with all its dependencies, must have a simple way to share that, in a way that does not require contacting anyone else.

- Bert -