Good note.  Some brief comments in-lined.

> 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
> ...
> 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
> ...
> place) but It Worked (TM).

In summary, what I took from that was how, sometimes, it's really nice
to have _modifiable_ system; including at the system-level classes and
below, even if it means you have a dirty package.

I absolutely agree these are exceptional cases; like maybe a video
game, for example.  But modifiable is core to Squeak philosophy and
something I want my package-loader to be able to do.

I also want my package-loader to allow me to _browse_ the contents
before I install it, so I can make sure it won't format my HD.
SqueakMap has that, of course.

> 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

I absolutely agree, which is exactly what happened with Connectors; I
reduced the number of "overrides" from a couple of hundred down to
just the 3 or 4 which weren't slam-dunk easy.

> of the packages we maintain. Of course, I am not currently a CSP maintainer,

Yes you are; CSP means "Community Supported Package" and you are part
of the community.  You or anyone can add a new release of Connectors
right now if you wanted.

> 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.

For overrides, I prefer change-sets.  BUT, I want to explain how I
deployed Magma 1.2 on a *modified* Pharo 1.1 and 1.2 platform using
SqueakMap without using ChangeSets and without using MC overrides.  In
a separate post..

> 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.
> ...
> Does this seem like a good idea? I am I making any invalid assumptions about
> what SqueakMap can be made to do easily?

I don't think this is necessary because we have the #bleedingEdge
release, which carries enough connotation to lower expectations.  It's
the version that is meant to be taken up with trunk development.  The
#bleedingEdge script for a package is written just once and then never
needs to change, unless new functionality introduces a new package
dependency, of course, but this is rare).

Then there are the legacy releases of packages which are targeted
always at some _legacy_ Squeak release.  The legacy release scripts
never need to change because the legacy Squeak release doesn't change
(unless someone wants to backport a bug fix, which is rare).

> +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.

Yep.

 - Chris