On Sunday, March 16, 2003, at 07:27 AM, goran.hultgren at bluefish.se 
wrote:

> (this post is quite long but hopefully a rather concrete proposal of
> action)
> ...
>
> 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?

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...

> 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?

Probably yes to all of these.  Packages in Carnival/Kitchensink should 
generally promise to behave with all of the other Carnival/Kitchensink 
packages, just like everything in the current image behaves with its 
various other parts. (well, mostly ;-) )

> ...
> 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.

Yes.  In practice, I was thinking this would be pretty simple, because 
for starters we could just declare all of the packages split from the 
current base image to be "Squeak official" (Celeste, Balloon3D, VM 
Construction, etc.), and all of the other ones to be "Not Squeak 
official".

But of course we do want the content of "Squeak official" to evolve.  
For example, the PWS package is something we could consider removing 
from "Squeak official"... it's not used much by anyone, has problems, 
and has been largely outmoded by Comanche.  And there are packages we 
could consider adding to "Squeak official".

But I don't think we want to radically change the content of "Squeak 
official" right away from what is currently the base image.  Probably 
we should wait until the image is mostly split up before making too 
many changes.

> 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.

> ...
> 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.

I agree that this sort of pipeline is worth considering.  We wouldn't 
necessarily need to adopt all of the various aspects of Debian.  For 
example, we could just continue to use Squeak version numbers (e.g. 
3.6, 4.0) instead of names like "Woody", etc.  I'm actually not sure 
about how Debian 3.0 corresponds to "Woody"/"Sid"/etc... is "Woody" 
simply an early codename for 3.0?  Or does Debian 3.0 represent a 
snapshot of the pipeline in its various stages?

> 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.

We should start thinking about it, at least. :-)  (regarding Step 3)

- Doug Way