stephane ducasse a écrit :
> Andreas
> 
> You are probably right.
> May be we went too down the road.
> Now try to explain this guy that merging sophie, croquet, OLPC package 
> problems
> is not due to traits.
> 

I am not a maintainer of anything serious as above now, but I speak with 
15 years of development on ParcPlace ST80 v2.3, Objectworks then 
VisualWorks. Sorry for the long answer.


GREAT Squeak CORE IMAGES ... :
-----------------------------

Plainly agree with the idea of a core squeak Kernel.

It is good to have an up-to-date kernel for newcomers and for starting a 
new project.

It is good to have prepared packages guaranteed to load into that image 
and don't break each other (Universe).

It is good that an up-to-date code repository be in sync with this core 
image, TRACING all the evolutions (Monticello).
Better than traditional change log IMO, because it is accessible on 
request, but you do not have to download a change log with whole code 
history. (Alternative being compress the changes and forget history).


...ARE IN CONFLICT WITH IMAGE-BASE DEVELOPMENT:
----------------------------------------------

But you can not force anyone to adopt your fresh kernel image at each 
release.
This won't happen for big application because it is too much work to do 
such a port, and this is not how Smalltalk-80 development takes place.

No you don't rebuild your application image everyday with all the tricky 
initializations and bootstrap process (circular dependencies), and all 
these objects that are not code, and won't reload that easily with code 
management tools...
You have something more comfortable, an already initialized image.

No, you won't go through this porting process when you know that some 
messages have been deprecated, renamed, some old crappy class replaced 
by new shiny ones, or some behaviour improved, the uncompatible way...

No, all these enhancements are not for free, because you'll have to 
review your existing code.

Switching to a new image is simply too many changes at once.

What you do is image base development. Developpers do copy an official 
image, perform changes, file out changeSet, Monticello or whatever, and 
all is integrated back in the official centralized image, where tested 
against non regression tests.

Isn't that pretty well what was done during 3.9 and 3.10 process ?
Yes, you smoothly and carefully change THE image.
I personnally downloaded 2 or 3 copies of each.
That's how it works.
You cannot blame major fork maintainer for doing the same.

When i was a commercial VW user and had to switch image, because the old 
VM would not necessarily be ported to new machines, that was a pain, 
there were ALWAYS some porting necessary.
We always needed a long transition phase. And development had to 
continue, so several images were maintained in parallel. What we did was 
backporting some of the changes from new official versions to older in 
order to smooth the process a little and reduce the difference between 
the branches... with change set and change files.

SO WHAT, NO SURPRISE
--------------------

Yes, this explains forks...
That is not a reason for throwing all your efforts away.
Keep developing a core image. This is the best way for integrating all 
these necessary clean up and enhancements.

Yes, the core image SHOULD harvest enhancements made in forks too... A 
huge ant work! No magic here, only communication and hard work.
Yes write tests and more tests to ease the process.

And what is needed is fine grained changes, that can be examined and 
harvested back in forks. If they ever want to port, this will narrow the 
gap. LevelPlayingField attempts to answer this very pragmatic goal.

Don't focus on Traits:
- as long as they are not used, they are harmless and won't prevent any 
backport.
- Even if used, you can still export equivalent generated code.
- Traits are not a problem unless you yourself want to change Class and 
Metaclass.
- Traits could be removed at will before starting a port

Without a doubt, build 3.11 on 3.10. Or if you really want to backtrack, 
build on 1.0 for licensing reasons (No, just kidding).

And please, update Mantis status, current management is a mess (issues 
harvested but status not updated).

Nicolas