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