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

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.

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

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

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

Daniel