On Mon, Sep 12, 2011 at 9:27 AM, Ben Coman <btc at openinworld.com> wrote:

> **
> Casey Ransberger wrote:
>
> Inline.
>
> On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Wed, 7 Sep 2011, Overcomer Man wrote:
>>
>>  I suggest a new fork or possibly a new orientation for the next Squeak
>>> release:
>>>
>>
>>  I guess we have too many forks already (compared to the number of active
>> developers).
>
>
>  +1
>
>   Adopt Cuis as the core image and focus on killer applications to attract
>>> new
>>> Smalltalk users.
>>>
>>
>>  Cuis is nice, but lacks features that are important for those killer apps
>> (e.g. internationalization). Also throwing aways years of work (3.8, 3.9,
>> 4.1, 4.2 and 4.3) sounds like a bad idea. We should pick good stuff from
>> Cuis (and Pharo) instead.
>> To make the image smaller we should do two things (in parallel):
>> - craving (make packages unloadable, remove dependencies, split packages)
>> - building (use Spoon to rebuild the current image)
>>
>
>  Yes, we should merge the best things from Squeak into Cuis, We should
> merge the best things from Cuis into Squeak. Until all are one.
>
>  WRT internationalization, though, I do feel that most end users don't
> need 20 languages they don't speak in the core system. Most users will want
> to use the system in a primary language. This stuff should all be available
> as rock-solid external packages. Not saying it isn't important, not saying
> that at all. If we hope to rebase Etoys on Squeak, internationalization is
> essential.
>
>
>> To make this happen we have to start with writing tests, which "document"
>> the expected behavior of the system. So when we change it, we can be sure
>> that we didn't lose anything important.
>
>
>  +1!
>
>  A living system needs a living specification, and the closest thing I
> know how to do to a living specification is a great suite of tests.
>
>  Let's start by merging the tests.
>
>   An interesting future scenario would be a shared test repository between
> the various forks of Squeak, with their respective continuous integration
> servers outputting results to a common database.   Differences in "good
> results " between forks should be catered for, but would highlight
> differences in the "specification" of each fork, which might help it to
> converge over time while allowing the implementations to differ.
>

An excellent idea!

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110912/8c91f071/attachment.htm