I must admit that lately I've been fairly sold on using SqueakMap to manage
Community Supported Packages, or "CSP"s (gah, a TLA. How irresponsible.) It
works nominally now and we can always improve it.

Further comments inline.

On Wed, May 4, 2011 at 6:09 AM, Levente Uzonyi <leves at elte.hu> wrote:

> On Tue, 3 May 2011, Chris Muller wrote:
>
>  see "Connectors" as a working example of this,
>>>>
>>>
>>> "* No conflicts. Neither class names nor -override categories. The
>>> rationale is that all community supported packages can be loaded
>>> together without creating conflicts."
>>>
>>> Collections, Kernel and System are dirty after loading Connectors,
>>> because
>>> it's "stealing" methods.
>>
>>
Overrides, right? I learned to loathe them passionately while completely
failing to keep Polymorph working in the Trunk when I first entered the
community. In the course of doing my Theme engine prototype in Cuis, Juan
and I found that in many ways such a system can be greatly simplified in
comparison by baking the behavior of the necessary overrides and workarounds
into the core system, or hanging hooks to attach the behavior to when the
external package is installed. The amount of complexity this adds to the
core system is rarely increased by a great degree -- it just needs the right
little hooks in the right places.

Since my Theme engine was only one class wide, and the simplest solution
involved the system needing at least one Theme (the default) installed in
order to function, we ended up including Theme in the core of Cuis. But the
vast majority of the work was about a) baking behavior which would otherwise
need to be overridden and was necessary or convenient for reuse into the
core system, and b) massaging out the behavior that I would ordinarily have
had to override which made less sense where it was into the Theme class
itself, which was originally intended to work as a loadable package.

The result ended up being looser coupling between structure and presentation
in the user interface surface and less code overall. The work isn't done
completely done, as there is still UI surface that I don't yet cover, and
code cleanup to be done (I had to look all over Morphic to figure out where
all of UI I wanted to skin was coming from, and make changes all over the
place) but It Worked (TM).

I do agree with Levente that we should avoid overrides in CSPs wherever
possible, even if that means doing the work to remediate the implementations
of the packages we maintain. Of course, I am not currently a CSP maintainer,
so I'm not sure I'm qualified to tell CSP maintainers what they should and
shouldn't do:)

OTOH, I suppose it may be more important to keep these packages updated and
tested with each release than to let them languish for want of some massive
refactoring to remove overrides while the core system diverges in the Trunk.
So maybe no-overrides is a counter productive rule. I don't know for sure. I
wish we could remove the feature from PackageInfo/Monticello entirely,
frankly, so that we can at least stop the bleeding right now.

Ok, but that's just a shallow problem with Connectors, not a problem
>> with the process or tools.
>>
>
> Currently it'a shallow problem, but if we want to maintain several (100+)
> community supported packages (and I guess we do), then it's have a great
> potential to break the system.


Sure. Is this a bridge we can cross when we come to it? Potential
application of the YAGNI Principle?

My point is that Connectors is fine on it's own at the moment, users are
> happy with it, but it doesn't play well in a larger system. The overrides
> ("stolen" methods) can break the base system and other packages in the
> future, while the insufficient number of tests may not prevent Connectors
> being broken by future changes of the base system.


Okay, first off, objection. How many tests are enough tests? How do you
measure that? Code coverage is usually a tricky metric, because there are
different granularities at work under the same monicker (e.g., line-level
coverage, block level coverage, method level coverage, etc.) and what code
coverage really tells you is what you know for sure that you *aren't*
covering. It never gives you a clear view into what you *are* covering. I
mean if your gut is telling you "there aren't enough tests here," I can
identify with that, but if we're going to make a rule about it, it will have
to be completely arbitrary, won't it? No subjective rule will ever work.

Can we put in place a process around addressing such problems? To my mind,
the situation is golden until we recognize that one of these regressions has
occurred. When such a regression is identified, the package can be flagged
as #broken on SqueakMap. We can even make the UI warn the user if he or she
attempts to install something that's been marked as broken. It can then be
fixed to work in the context of the release that it's broken in, and the
#broken flag may be removed. This way we can maintain external packages in
the context of updates to a release.

Does this seem like a good idea? I am I making any invalid assumptions about
what SqueakMap can be made to do easily?

Before we subject ourselves to rules, let's ask what is the basis for
>> needing them?  From Andreas' original note:
>> <snip>
>
> The goal is stated as, "one-click loadable" and "we provide assurance"
>> (which is difficult especially when one reads MIT license), but I
>> think this might be about _branding_.
>>
>
> Don't take assurance literally, it only means that you can expect it to
> work out of the box.


+1, and we should remove this from the language we use to describe CSPs,
too. Find a way to say what we mean without inadvertently implying that
there's a warranty.


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110504/bf95a4ad/attachment.htm