cut lots of other stuff again :-)

>> But we are a bit afraid that such effort would not be taken in easily.
>> Again, initially this will have rough edges and no documentation.
>
> These two last lines are then the interesting part to discuss further.
> A few off the head remarks:
>
> - I have a hard time seeing anyone objecting to general improvement. 
> :-)
>
> - Experimental stuff should of course be kept in non-core SM packages
> until matured. Again, this other issue needs discussion. In any way the
> modular future should make it easier to handle these "controversial"
> changes because it will not be a black/white thing (you get into the
> image or not).

Exactly. Long live separation, especially for these things.

>
> - We are talking about major contributions here and we can surely adapt
> and make some targetted effort for them. (The current harvesting 
> process
> is limping but we are trying to get a handle on that - but it will take
> a while)
>
> So I don't think you need to be afraid of getting good stuff 
> "accepted".
> :-)
>
> Instead you *should* be afraid of the fact that there will be few 
> people
> around to help you out.

We are aware of that, and it is only normal.

> We (he, not implying that I count myself into
> this group) aren't that many that can tackle these areas and those that
> can may not have much time to offer. So you need to do some serious
> "marketing" and "community tending" to drum up the adrenalin and get
> that help. Anthony, Daniel and Andreas are obvious targets for this
> stuff - but there are of course a few more people out there that can
> "wield the magic of meta classes". But not *that* many.

No, again, that is to be expected. You need to have a serious 
willingness to investigate time for these things.

>
> [SNIP]
>>> Finally - I am confident we will make the best of this all. We just
>>> need
>>> to start thinking in terms of how to manage the cooperation in the
>>> community. Earlier this was not a "problem" because we more or less 
>>> had
>>> a benevolent dictatorship (SqC). Now when we are moving over into a
>>> community shared mode with distributed "ownership" of packages etc, 
>>> the
>>> "tending" of the community turns into a much more complex job.
>>>
>>> And given this I would like us to formulate - as a start - these
>>> package
>>> groups I was talking about and how they should be allowed to depend 
>>> on
>>> each other. This will give us a "planning table" where we can place 
>>> the
>>> packages and see how they should/would/could relate to each other.
>>>
>>> I think I need to fire up that issue again in another thread. It was 
>>> a
>>> mistake to put both in the same thread. ;-)
>>
>> Then I'll wait for your mail there :-)
>
> Ok, give me a few hours - or you could start it yourself of course :-) 
> -
> I need to do some Dolphin here. It is a *really* important discussion I
> think and we need to get cracking in that area.

Agreed again. But I am driving back later on from Belgium to 
Switzerland, so I'll wait for your mail. Let's rock :-)

>
> regards, Göran
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org