[squeak-dev] Re: SqueakMap soon working in 4.0/4.1!
asqueaker at gmail.com
Tue Apr 13 14:59:49 UTC 2010
> 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.
SM is not about "the future", it is about the "past". It's a reliable
archive of past works, how to load them, what image they last worked
> IMHO we need something similarly simple for a package management system for Squeak. Something where it is easy to share. If one user figures out how to get a particular package to load, it must be trivial to share that method. And submitting one such "package loading instruction" must not sign up the user to be perpetual maintainer of the package.
> So I think the private "ownership" model is flawed. We need a package management system that allows easy contribution. Maybe SqueakMap can be restructured for this, but currently it seems heavily geared towards single maintainers.
I'm not against trying to address this issue; but I just want to keep
our focus on the fact that we don't need SM to be as flexible as our
SCM toolset because it is fulfilling a different role.
More information about the Squeak-dev