Debian vs SqueakMap was: Pink Plane vs Blue Plane
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Thu Feb 13 13:58:21 UTC 2003
Martin Wirblat <mw.projanynet at SoftHome.net> wrote:
> 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.
Ok, well, perhaps I did misread you a bit "on purpose". Anyway, then we
are in agreement. :-)
> >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.
Yes, we can easily create a few categories to capture this "grouping" of
And we should definitely do this. We have "Package type" and "Package
Perhaps we should create "Package group" and let it have these three
subcategories that we are talking about "Core packages", "Extra
packages" and "Experimental core replacement packages". Or something
> Anyway, I'm glad that you just sounded somewhat more wild than
> your plans are :-)
Hehe, is that a compliment or should I be offended for boring plans? ;-)
> regards Martin
More information about the Squeak-dev