Hi all!

Doug Way <dway at riskmetrics.com> wrote:
> 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...

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.

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

And btw - the upcoming SM will have a proper package cache. This means
that a Squeak-zip can contain a subdir "sm" which includes the package
cache in which we can cache Kitchensink or any proper subset of the
package releases on SM. In short - the downloadable zip doesn't need to
contain a Kitchensink *image*. It can actually contain a kernel or coder
image with all the kitchensink packages in the package cache available
for easy installation through load scripts.

That seems pretty neat to me. And IIRC this was more or less how
StableSqueak was delivered too.

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

I agree that this is an obvious first approach.

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

I agree again. No need to rush it in 3.6. We can do that in 4.0 instead!
Sidenote: 4.0 should probably contain the work of Anthony and the new
image format btw. Darn, I learned how to use continuations in the
weekend (got a free lecture from Riastradh on the Squeak IRC channel)
and I am itching to play with them! :-)

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

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

Debian 3.0 is Woody. Woody, Sid etc are the names of the "package pools"
or whatever they are called.
Think of it as a long line of package release buckets. They all have
individual names but the last three are often referred to as
stable/testing/unstable. So these three labels are relative names.
Before 3.0 testing referred to the Woody bucket. Now it refers to the
Sid bucket. And unstable refers to the newly created bucket called Sarge
(Ah, remembered it).

So before the release of 3.0 it looked like this:

	...[earlier buckets] Potato(stable) Woody(testing) Sid(unstable)

and then everything was shifted one step and a new bucket was created
for unstable:

	... [earlier bucets] Potato Woody(stable) Sid(testing) Sarge(unstable)

And finally, if you download Woody (current stable) aka Debian 3.0 you
will get that bucket. Not the whole pipeline.

Regarding if we should use version numbers instead of codenames - well,
that may confuse even more. I mean, as soon as we start to use 3.5 or
3.6 on this list people tend to get confused which one is the *current*
version. Perhaps we shouldn't use version numbers until it in fact *has
been released*. That is probably the reasoning in Debian.

Note: There may be subtle errors in the description above, correct me in
that case.

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

Goodie. Please feel free to refine or critique this proposal even more.
Step 1&2 are especially important to get concensus on (and I *don't*
mean the darn layer names).

> - Doug Way

regards, Göran

PS. Richards proposal of using words like Small, Large, Minimal, Normal
etc sounds good too. :-)