Hi Göran and all,

I agree with Issue 1 :-)
However I would emphasize that it may be important to have something 
like 'Next Core', a whole and complete thing, otherwise it may get 
hard to get the next core ( = release ) working. So I would suggest 
'Core Replacement' for packages that are potentially meant to be in 
'Core' or 'Next Core' but where it is not clear if at all and in which 
combination and 'Next Core' for the next release which is meant to 
completely replace 'Core'. Thus we would have something like a 
pipeline as Debian has. 

I think traits should live in 'Core Replacement' and if we get the 
feeling that it is the logical evolution path for Smalltalk the 
language it should made it to 'Next Core'. To put it immediately in 
'Core' is illogic, even without having 'Next Core', because 'Core' is 
the actual release. Traits have not been tested and commented by many 
people yet. 

With all what we may do, I think it is best to have *ONE* Squeak, even 
a not perfect one, be it compatible with other Smalltalks or ANSI-
Smalltalk, or be it less compatible, but to have two Squeaks, i.e. one 
with and the other without traits, is the direct path to hell. The next
time we will end up with four Squeaks....

In fact it is a reductio as adsurdum of the idea to have one small set
of parts which gives you many different wholes.

regards,
Martin



goran.hultgren at bluefish.se wrote on 14.02.2003 13:22:54:
>
>Hi all!
>
>I thought this list was so "quiet" so I just had to start a new
>thread... :-)
>
>There are two (well, 723 to be exact, but these two are interesting)
>issues we really need to start discussing:
>
>1. Package grouping/blessing, package ownership, allowed dependencies
>etc.
>
>2. Traits.
>
>In different threads the last days we have been discussing how to
>prevent chaos when we start tearing the image to pieces and putting
>stuff on SqueakMap instead.
>
>Sidenote: We might want to wait a bit until *really* removing packages
>from the image - at least until SM1.1 is out. There are a bunch of 
>good reasons for that.
>
>Issue 1
>========
>
>....is about how we should group our packages. Here are a few 
>suggestions: 
>
>Core packages - these are typically packages currently in the base 
>image and they more or less constitute what we like to call "Squeak". 
>We will probably have different "rules" for how to maintain these - 
>higher standards, cooperative ownership etc, what do I know. Packages 
>in core can only depend on other packages in core of course. 
>
>Extra packages - these are packages not regarded as core but 
>nevertheless packages that applications etc tend to rely on. They are 
>typically personally owned and maintained but the maintainer is aware 
>of the fact that the package is important to many others. But they 
>aren't core - so some relaxation exist. Packages here can depend on 
>both packages in core and in Extra. 
>
>Core replacements - these are packages that can not coexist with one 
>or more packages in core. A Morphic replacement would typically be 
>here. Depending on one of these packages is obviously quite risky and 
>would greatly increase the risk of conflicts with other packages. 
>Experimental rewrites of core packages will live here until they can 
>actually step into core and replace the old packages. Packages here 
>can depend on both packages in core and in Core replacements. But 
>when moved into core they can of course only depend on packages in 
>core. 
>
>Normal packages - well, the rest. :-) Here we have all the 
>applications, tools, you name it. They can depend on packages in all 
>other groups. Depending on packages in Core replacements is on the 
>other hand a pretty dicy thing of course. 
>
>Ok, that probably got your brains in gear... This is a very important 
>question for us to sort out. Implementation is on the other hand very 
>easy - we simply add a few categories on SM for grouping. So, shoot. 
>
>
>Issue 2
>========
>
>Issue 2 is somewhat peripherally connected to the above. Traits is 
>standing outside our pretty little Smalltalk-80 descendant house and 
>is knocking on the door. What does this mean? If Traits was a package 
>- 
> where should we put it? In core? Ok, that would essentially mean 
> that Squeak is taking a step away from Smalltalk. Squeak simply 
> isn't a "Smalltalk-80 clone" anymore. And the argument that Traits 
> is optional to use doesn't hold - people *will* use it and that will 
> change *a lot*. 
>
>Personally I do think it could be placed in core. It seems to be such 
>an elegant extension solving a lot of problems. But some people 
>probably wants Squeak to stay as a "Smalltalk clone" and be as 
>compatible with other Smalltalks as possible. Well, I am not one of 
>them - but it will be interesting to see the discussion unfold. 
>
>What if we put Traits in "Extra" then? Sure, that is a compromise 
>that may work. But then we will loose a lot of the real good use of 
>Traits - 
> to untangle our core packages like for example Collections or 
> Morphic. 
>  Because we can't have packages in core depending on packages 
>  outside of core. So that doesn't really sound like an interesting 
>  option. 
>
>So, again - a very interesting challenge I think. Are we going into 
>the future or are we staying in the eighties? :-) Can we do both? 
>
>Well, fire away. But let's keep it civil. ;-)
>
>regards, Göran