On Saturday, April 5, 2003, at 04:57 PM, Daniel Vainsencher wrote:

> Please don't read this mail negatively. I don't want to see your work
> picking up dust. And the SqF thread has positive, project specific
> suggestions, which I prefer not to repeat (OAOO).

I did not take negatively
>
> Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
>>>
>>> [changes not independent]
>>> For the general harvest process, this would make me not approve them.
>>> But I answer your specific case on the SqF thread.
>>
>> How can we create changeset that are not dependent. If I move method A
>> from class B to class B. Then if later on we want to fix another 
>> aspect
>> and we have to modify method A this method A will be on classB. So the
>> two changesets ARE dependent. Sorry I do not see how we could do that
>> in another way.
> Bunch everything that is closely dependent into one changeset. Continue
> working on that issue after it is accepted. Just look at how other 
> stuff
> is done - the granularity you're using is VERY VERY fine. It has it's
> advantages, but some disadvatanges, too.

I was thinking that this was what the people wanted because having a 
bigger granularity will help us to go faster but may make the harvested 
more difficult.
That's why we did it like that but we can change this.

>
>> But I'm not on SqF list.
> Stef, you started a thread there. I assume you're going to read it,
> right? if you post to a list that you're not registered to, it is
> customary to explicitly say in the body "please CC to me".

I forgot.

>
>> I want to say that this would be easier for us to work like mad during
>> 3 weeks and
>> produce a new kernel than generating tiny changesets one after the
>> other one.
>
> But I'm sure you realize, that depending on how complicated it is,
> nobody can promise you that it would be even reviewed, never mind
> accepted.

Exact so that's why we choose the fine grain approach.

>
>>> I'm trying to understand what should in your
>>> opinion be the functionality of the kernel, and what should be 
>>> outside.
>>
>> UI should be out,
>> everything related to class compiled method should be in. I do not 
>> want
>> to go into the detail but we want to have a core with layers and be
>> able to deploy a image with just the core so we should not have
>> dependencies between core layers and external layers.
>
> I caution you - this is an open project. To the extent that you close
> your process by delaying other people's access to your design
> directions, you risk them not being accepted.

But we close nothing. Just open a browser and look inside. This is just 
that
I do not have hours to spend explaining why the kernel is in a bad 
state.

> It's your call. I want a
> clean kernel, but if I see iffy decisions implemented, I will have no
> qualms about  pushing to reject them.
>
> Pushing out UI is clear. How about global analyses (like
> unSentMessages)? seems to me that is another direction that can be
> extended in arbitrary forms, and should be pushed out.

if it is not build uniquely on core behavior it should be moved into 
SystemNavigation.

>
> No problem if you disagree, but state the design decisions that drive
> your implementation.

We did that on the wiki and again I do not have hours to explain that.


>
> Daniel
>
>
Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html