>> But we never had problem with that.
>
> Good. :-)
>
> No, but seriously - I just got the impression that... well, this can 
> get
> hard to express in a non-native language. Hmmm. It sounded to me that 
> if
> Squeak as a community "wouldn't do this and that" then you would simply
> leave and pick another Smalltalk.

[Let's try to reply properly in our non-native English :-) ]

Kind of, but not that black-white really. We are just evaluating what 
we need for a second-step traits (and Classboxes, our module work, and 
some even newer things). Like Stef said, certain infrastructure should 
be tackled, and we are willing to help with this, invest time there, 
and take some responsibility. So it's not that we expect the community 
to do lots of things and that then we would bless/curse them with 
something like traits :-) We expect to do a lot of the work there 
-which is not a problem- but something will have to come from the 
community: playing with these things, with a minimum of documentation, 
providing feedback, and helping out. I'd like to take the StarBrowser 
as an example (although it is not completely what we have in mind). I 
just did an initial port with minimum functionality, and Ned took over 
from there. This was good because that way the browser is taken up by 
the community (at least by one member :-) ). It was not good that I was 
not able to help Ned much - I couldn't catch up with him once he 
started :-) The reason is that the StarBrowser is my late-night fun 
project, not research work for which I have proper time during the day. 
So for traits, the parser, browser, ... etc. I think a likewise 
approach should work, but we will be able to invest much more time in 
it and drive the initial effort.

So, in short, we want to do some core work to the language (since we 
need it anyway) and want to provide the results back to the community). 
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.

>
> And that got me a bit scared. :-) Well, today it doesn't matter - but
> tomorrow when Traits is all over the place and Nathanael has rewritten
> large parts of the core ;-) then it would be devastating if you 
> suddenly
> decided to just dump Squeak.

No, we understand that and it will not happen. Committing is committing.

>
> I simply want to be reassured that people who are going to rewrite
> (possibly) large parts of the Squeak kernel/core are *really committed*
> to Squeak and to the community.

Yes, we hear you.

>
> I hope I managed to explain this without offending anyone. :-)

Absolutely.

>>> And I would like to feel that the people working with Traits consider
>>> Squeak both as the home of Traits but also as the community where
>>> Traits
>>> grew and evolves.
>>
>> Goran what is important is the synergy: if we come up with a cleaner
>> stabler squeak,
>> then we could get a cleaner, stabler Traits model. After we can build
>> academic evolution
>> and the Squeak Traits can stay or evolve at wish of the community.
>> I think that what is important is that nobody got frustrated in both
>> sense.
>> That's why I liked the email of andreas. Right now I'm looking at how
>> metaclasses property composition behaves in presence of traits but 
>> this
>> does not mean that we would have to refactor everything upfront.
>>
>> Stef
>
> 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 :-)

--
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