It lives on SqueakMap, no? Not in the image we ship? It has *some* tests that tell us if we've *completely* broken it come next release?

I kind of feel like if Chris is maintaining it, this is golden. Connectors is wonderful and well known. So is Chris. Win win win. 

If we throw out the rules and look for an actual problem, is there an actual problem? Or is it just that we need to refine the rules a little bit?

On May 3, 2011, at 9:56 PM, Chris Muller <ma.chris.m at gmail.com> 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.
> 
> Ok, but that's just a shallow problem with Connectors, not a problem
> with the process or tools.
> 
> It's fair enough to say Connectors might not be good enough to put a
> Squeak-CSP trademark brand on it yet.  A collection of quality
> criterion like tests and unloadability sound fine to associate with
> "Squeak-branded" software; to help people feel comfortable and know
> which packages can be regarded as "the best".
> 
>> "* Tests mandatory. A community supported package MUST have tests. The
>> rationale is that since we provide the guarantee that the package has
>> been tested, we need to ensure that testing can be automated to the
>> maximum extent possible. It doesn't mean 100% coverage but *some*
>> meaningful set of tests need to be provided or else we can't say if we
>> broke it in the latest update."
>> 
>> There are only 4 tests, which is very little. The tests leave garbage on the
>> desktop and when you want to get rid of it, you'll get debuggers.
>> 
>> So Connectors doesn't match these requirements.
> 
> _All packages will forever always be in some sort of _improvable_ state.
> 
> Before we subject ourselves to rules, let's ask what is the basis for
> needing them?  From Andreas' original note:
> 
> ----------
> "A community supported package is a
> piece of software where we feel this is an important/interesting/novel
> package that should ship with this Squeak version. A community supported
> package can be loaded in a 'one-click' process directly from within the
> image. A community supported package is a package where we provide
> assurance that the package has been tested for this release.
> 
> However, that status does not come for free. In return for achieving
> this status, the software needs follow the rules "
> ----------
> 
> 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_.
> 
> The original author of Connectors had long since departed the
> community, but it is a fine piece of software I wanted to bring
> forward from 3.9 and make it one-click installable and usable on 4.2.
> After getting as close to "perfect" as I could afford to invest, I
> simply wanted to find a way to _capture_ that work and make it
> consumable and improvable by others, as a currently #bestAvailable or
> #stable version for 4.2.
> 
> I also made a #bleedingEdge release whereby we could collaborate on
> Connectors as a community in the same way we do for trunk; and
> included that in the announcement.
> 
> At least to a degree, it worked!  I have gotten e-mails from others
> who have since gotten use out of it, notwithstanding those dirty
> packages and broken rules.  :)
> 
> - Chris
>