[squeak-dev] Re: SqueakMap soon working in 4.0/4.1!
bert at freudenbergs.de
Tue Apr 13 19:50:33 UTC 2010
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 -
More information about the Squeak-dev