[2] Debian vs SqueakMap was: Pink Plane vs Blue Plane

Martin Wirblat mw.projanynet at SoftHome.net
Thu Feb 13 12:52:06 UTC 2003

goran.hultgren at bluefish.se wrote on 13.02.2003 11:29:21:

>Nah, I don't agree with this one. I do agree however that it should be
>clearly noted that hey - this is Morphic2 - proceed at your own risk
>etc. Rebuilding core parts may very well turn out to be a very
>interesting area - we are doing it all the time, Nathanael has rebuilt
>Collections, people are thinking of rebuilding Scanner, Parser etc. 
>And sure, we can mark these "core clones" as being that and thus 
>clearly "dangerous ground to stand on". But we can't forbid anything.

Hi Göran 
maybe I was a bit unclear, I meant a basic clone like Morphic2 should 
not be allowed in what I call the 'base' and what you call 'fundamental
core packages'. It should even not be in what I call 'rest' - most of
the current SqueakMap packages, because it is a clone for a part of the
'base'. Of course it must have a place, and to have a bit of coherency
to focus work on one successor-'base' I suggested 'baseExperimental'. 
I really don't want to forbid people to produce Morphic2.

>I think I am putting a bit more trust in "evolutionary" forces here.
>If someone creates Morphic2 and it is vastly better than Morphic,
>packages may start using it and sure, those packages are paying a high
>price because they will not be able to coexist with other packages 
>based on Morphic. Either they will die, move over to Morphic or... 
>Morphic2 will turn so popular that this disadvantage doesn't matter 
>to the users. In that case we have competition and one of the two 
>will probably win out because the community isn't large enough to 
>accommodate both. 
>Or they will merge.
>IMHO we can't possibly "forbid" people to produce Morphic2. Instead SM
>(with dependencies etc) should provide a good playground for the
>packages to "fight it out" in an orderly manner.

Evolutionary forces need a guidance. My idea was to make sure that 
there is a 'base' and its successor which is to replace eventually the 
'base'. Same as in Debian here, they have 3 or 4 versions in a row, 
and whenever one becomes the actual release, the others move up, and 
the last release gets obsolete. I think it should be prohibited that 
suddenly we end up with many bases, and can't go back to one. A 
structure of SqueakMap which reflects i.e. this idea would be helpful 
to give evolutionary forces the right fences.

Anyway, I'm glad that you just sounded somewhat more wild than
your plans are :-)

regards Martin 

More information about the Squeak-dev mailing list