Re: Meeting with Edgar notes

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