Branding criteria (was: Re: [squeak-dev] Modularity)

Levente Uzonyi leves at elte.hu
Wed May 4 13:09:02 UTC 2011


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

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

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.

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

Don't take assurance literally, it only means that you can expect it to 
work out of the box.

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

I'm sorry if it wasn't clear, but the main point of my previous mail was 
not about Connectors being bad. I hope my explanation above clarifies
this.


Levente

>
> - Chris
>



More information about the Squeak-dev mailing list