About 3.6 alpha process: to break the less

diegogomezdeck at consultar.com diegogomezdeck at consultar.com
Wed Jun 4 13:12:45 UTC 2003


Please re-read my previous email COMPLETLY before answering.

> Diego
>
> if this is your conviction, do not participate. But I think that
> this brings us back in prehistorical ages....monolithic ages.
>
> Stef
>
>
> On Wednesday, June 4, 2003, at 11:37 AM, <diegogomezdeck at consultar.com>
>  wrote:
>
>> Hi Stef,
>>
>>> Hi all
>>>
>>> From my point of view I did not get a clear answer to my question.
>>> How do you think we should proceed.
>>
>> You asked, I assume you want to hear my answers.
>>
>>> Now I'm stuck: working in 3.5 and producing a lot of
>>>  changesets that will not load in 3.6,
>>> spending time to remove the change related to the removed
>>> classes.....I
>>>  still think that wer are doing too much
>>> at the same time.
>>
>> IMO, This is not the source of the problems.  The source of the
>> problems is
>> the extreme-minimalist approach that caught us.
>>
>> We are trying to make the standard image smaller and modular but we
>> have
>> not support at all to do that.  The current version of Squeak (and I'm
>>  not
>> meaning the size of the image) allows the mess, so the mess will be
>> there.
>> (pseudo-off-topic: did you read "Behavior of Information"?
>> http://www.truxton.com/~trux/etc/boi/).
>>
>> We trust that a smaller default image will solve our problems but, in
>> fact,
>> we're creating more problems than then problems we're fixing.
>>
>>> If I have one hour to clean the kernel, I do not have
>>>  one hour to fix the changesets I already produced and fix the
>>>  kernel.
>>
>> This is not the worst part of the history.  The worst part is: The
>> work we
>> (mcp & kcp) are doing will vanish with the nexts updates.
>>
>>> So I will try to find some time to play with conflictchecker but
>>> again I will not be cleaning.
>>>
>>> I agree with tim, I would like to arrive fast to a core that is
>>> stable and I would like to focus on that and push the other guys here
>>> to  help.
>>
>> So, my short answer is: If we want a modular image [*], let's
>> implement some modules mechanism before creating the pseudo-modules
>> we're working on.  Probably we'll need also some type of namespacing
>> support.
>>
>> [*] I'm not sure I want to pay the price to have a modular image.
>> When I
>> work with ST-Dialects with packages/parcels/application/yourNameHere I
>>  feel
>> so constrained.  The monolithic image can have problems, but the
>> freedom it
>> gives is not present in more-declarative environments.
>>
>>> Stef
>>
>> Cheers,
>>
>> Diego





More information about the Squeak-dev mailing list