(this post is quite long but hopefully a rather concrete proposal of
action)

Cees de Groot <cg at cdegroot.com> wrote:
> On Sun, 2003-03-16 at 09:27, Craig Latta wrote:
> > 	So, I'd rather see something like "mechanic, writer, audience", perhaps
> > in the context of a cinematic theme.=20
> 
> Duh. Craig, for a=20
> > improvisational musical informaticist
> you're pretty boring ;-}.

;-)

> I have to agree with Doug - I've come to like the kernel/coder/carnival
> names. Let there be clowns!

I actually think it's ok too - I like a bit of "self distance" as more
humorous names implies.

> (hey, it's just the canonical thing, remember - I still hope that by the
> time we get these three sorted out, we will have many images released by
> many people for many targe audiences).

Right, and that brings me to the real reason for posting. This very long
thread (funny how especially the problem of naming things create
humongous threads) started with your suggestion of a triad. Kernel,
Core/Coder and Base/Full/Carnival. This in turn was triggered by many
other posts regarding Stewards, Debian vs SqueakMap, package grouping
etc.

The argument for this triad is good. It is a simple "layered" approach
so people understand it - strict dependencies downwards according to the
gif I posted.

But there are a few aspects of this discussion I want to revive:

- 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? If a package is in Carnival instead of
being a simple personal package posted on SM - does it mean anything?
Can a package in Carnival be trusted to have been tested along with all
the other packages in Carnival? Must the packages in Carnival be under a
certain license?

- The Debian "pipeline". I like Martin Wirblat's simplified model of my
first feeble attempt at this. In essence he proposes to adopt a "Debian
pipeline" for Squeak (kernel+coder+carnival, well, he called it "core" -
but we hadn't yet defined these terms then) with three levels, just like
Debian has. When this proposal was made by Martin not many replied.

So, trying to condense this into some form of concrete simple proposal:

1. We start by going through packages on SM and decide which of these we
want to consider as "official Squeak packages". So a given package is
either a) Squeak official b) Not Squeak offical. This has nothing to do
with layers (kernel/coder/carnival) nor the pipeline. This would clearly
establish the outer border of the shared Squeak artefact that we all
want to be able to depend on. An official package would *currently* need
to be under Squeak-L (plus any additional licenses of course) and the
maintainer would of course need to agree, since it places at least some
form of "expectations" on his/her shoulders. NOTE: This would be done
using SM categories and also note that this is a categorization of the
*package* and not of a specific *package release*, see below.

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.

NOTE: SM categories can change name. So please, by all means, continue
fighting it out - it doesn't stop us from introducing these categories
now. :-)
NOTE2: A package release can only be in *one layer* at a time.

3. The pipeline (stable, testing, unstable). According to KISS I would
like to simply adopt the names that Debian use. Many people know Debian
and the names are pretty good. Well, "testing" is perhaps a bit odd but
whatever. :-) The pipeline is essentially three different "update
streams" governed by different rules. Unstable is more or less like
"anything goes". A new package release always enters unstable first.
Typically only developers track unstable. When a package release has
been in unstable for a while and some criteria are met (no bugs reported
in a certain timeperiod etc) it enters "testing" (is this automatic in
Debian? Not sure.). Many users track "testing" since it is more fresh
than "stable" and normally is stable enough for desktop use. Testing is
then regularly "frozen" and eventually, when it looks good and solid, it
is proclaimed as the new "stable", "unstable" turns into "testing" and a
new "unstable" is created. To begin with we can create these categories
in SM and use the following simple procedure:
	- All new package releases are categorized as "unstable" from the
start.
	- If a package release in unstable is not manually "blocked" it
automatically is "copied" into testing after a specific amount of time.
This means they will trickle into testing but we can always go in and
block a release if it turns out to have problems. Since we don't have a
"issue tracking system" yet this will have to do.
	- When we are getting closer to a release we can "freeze" testing so
that the auto-trickle from unstable is blocked. At this point in time
only branches off of the package releases in testing are allowed into
testing. In short  typically only bugfixes are allowed.
	- Stable only changes when bugfixes are needed.
	- When testing is proclaimed as "stable" then we move all the package
releases in testing into stable, move all the packages in unstable into
testing and create a new unstable.
NOTE: SM uses Stephen Pairs VersionNumber package for automatic version
numbering and that supports branches.
NOTE: A package release can thus be in unstable and testing and stable
at the same time. Compare this with the layers discussed above. So
stable/unstable/testing are simply three Sets which can overlap.
NOTE: Typically stable/testing/unstable are simply aliases for specific
package release Sets. When a new unstable is created it is given a name.
The current stable in Debian is called "Woody". Woody was "testing"
until recently when Debian 3.0 was released. Now "Sid" is testing, can't
remember the name of unstable right now.

Ok, phew.

Step 1 can be done today. Step 2 can be made as soon as we get SM1.1.
Step 3 is also dependent on SM1.1 and would also need a few new
mechanisms on top of that, like the simple ones described but foremost a
good system for describing and resolving dependencies. But we have such
a system "all thought out" :-). So in short - we can't start using the
pipeline until we have SM1.2. It would on the other hand be interesting
to know - since I am hacking on SM1.1 - if we are aiming for this kindof
setup.

regards, Gšran