[Squeakfoundation]Stewards and Squeak Packages
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Fri Mar 7 16:24:11 UTC 2003
Hi Cees and all!
Cees de Groot <cg at cdegroot.com> wrote:
> On Fri, 2003-03-07 at 14:48, goran.hultgren at bluefish.se wrote:
> > Sounds good. Should we have *one* official kernel and then of course
> > people can register their own variants on SM?
> Probably. However, there should be very strong pressure against variants
> on this level, IMHO.
Yeah, but that kindof takes care of itself I think. There are already a
whole bunch of people working with creating mini images etc. But if
someone really delivers and it looks good it will quickly turn into a
defacto kernel and we can then "bless it".
There will always be other special needs and the important thing is to
know which is "The One" that 99% of us use.
> > So "core" is the baseline that you normally (unless building something
> > of your own on top of a kernel directly) "know" is there. And it is a
> > superset of the official "kernel" I assume.
> All three are strict supersets. Not that it is necessary, but it is
> easier to build and explain, I think.
> > Would "base" also be the boundary of everything maintained by stewards?
> > I mean - does base define what we call "Squeak"? Does it include all of
> > the stuff that we - as a community - considers to be "ours"?
> That's probably too much. As I said - lots of room for discussion here,
> especially at this level.
I want more arguments against. If you stand by the "too much" statement
here we end up with 5 different groups of Squeak packages:
1. Kernel. (True, False, Array etc)
2. Core. (DisplayScanner, FontSet etc)
3. Base (Browser, Workspace, Debugger etc)
4. Stewarded packages not in base
5. Extra packages (everything else practically)
I am not sure why we would like to have stewarded packages outside of
Base. Isn't the point of Stewardship that it is a "basic piece of
Squeak" that the community cares a lot about? (Compared to say HttpView
that is just an Extra package by some dumbwhit who hasn't turned into a
> > Yes, I like it and I buy it.
> Good. I knew you were smart enough to understand my arguments ;-)
Of course - I only accepted them so that you wouldn't consider be dumb!
> > So, to get practical - should we introduce these three as Categories in
> > SM? I would think so.
> That is a very sensible first step, I think. And post (my) definitions
We can let this thread live a day or two so that others can chime in -
and I also would like to cross examine this against Martins Debian vs
Otherwise I really would like to have a category called "Package group"
or something. It would probably be mandatory. And it could then have
I think we also should create one Swiki page for each of these 4
categories where we explain them in depth. And I also would like to have
a good "oneliner" for each.
So... note that "Kernel package" above does not mean that it *is* a
kernel. It just means that this package is included in "The Official
Kernel". So, hey - Colin, what do you have to say about that? ;-)
> > And then of course a fourth is needed - "extra" or "other" or something.
> > And should this category be mandatory?
> BTW categories: did you consider something Trove-like?
Actually, I have heard of Troves and seen it in several of these "tools"
around the net but I honestly don't know what they really are (except
for some kind of graph representation, right?). If you have a good link
I can check.
I carefully tried to make SM minimal in nature (no XML for example), it
only depends on vanilla Squeak stuff. I also wanted maximum flexibility
so even though I knew there was something called Troves I didn't check
More information about the Squeak-dev