On Monday, March 17, 2003, at 04:04 AM, goran.hultgren at bluefish.se 
wrote:

> Doug Way <dway at riskmetrics.com> wrote:
>> On Sunday, March 16, 2003, at 07:27 AM, goran.hultgren at bluefish.se
>> wrote:
>>
>>> - Drop the focus on audience for a while and think about the "outer
>>> border" of Squeak. As suggested - is Carnival the outer border of
>>> "community managed" packages?
>>
>> I would say yes.  To have some "community managed"/"Squeak official"
>> packages outside of the Carnival/Kitchensink layer would add another
>> defacto layer, which is more complexity than I think we probably 
>> need...
>
> Right. Just a little note here - this means that Squeak official will
> never get "larger" than Kitchensink.
> Kitchensink has been argued to be the thing that a newbie downloads and
> plays with. That means we have a practical size limit to think about.
> Limiting Squeak official to that limit seems a tad wrong to me.

You have a point here.  I guess I'm not strongly opposed to having some 
"community managed"/"Squeak official" packages that aren't necessarily 
in the Kitchensink distribution.

But I'd say for a while at least, we might want to limit the community 
managed packages to the Kitchensink layer and below, and put off 
worrying about this possible outer layer until later.

> But note: This is not an immediate problem or anything - its just 
> layers
> - we can always add/remove layers later. So I buy it for the time 
> being.
> :-)

Yes. :-)

>>> 2. Layers (kernel, coder, carnival) and the pipeline are formed by
>>> categorizing *package releases* (not packages). Marking a package
>>> release as "Coder" is essentially a promise that it only depends on
>>> *package releases* that are also marked as "Coder" (same layer) or as
>>> "Kernel" (the lower layer). That is actually all it means! So we 
>>> simply
>>> create these three new categories (Kernel, Coder, Carnival), go 
>>> through
>>> all packages in category "Squeak official" (see above) and categorize
>>> their package releases accordingly. Then later, when the maintainer
>>> posts a new package release for one of the Squeak offifical packages
>>> then he/she is forced to pick one of these three categories. These
>>> categories can then of course be used to produce "load scripts" 
>>> (=image
>>> build scripts) that in turn can build images for distribution or be
>>> easily loaded through SM.
>>
>> Sure.  Although I imagine a package having one release in "Kernel" and
>> another release in "Coder" would be pretty rare.
>
> Well, not so rare that you may think. It is what will happen when a
> package is moved from one layer to another. Will obviously happen from
> time to time.

True, I guess it will tend to happen as we're trying to figure out 
which layer a package really belongs in.

- Doug Way