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
|