Doug Way <dway at riskmetrics.com> wrote:
> One question I have for the Debian users out there, related to the recent
> release timeline discussions... how often does a new Debian release come out? 
> (i.e. roughly how often does the Debian "testing" release move to "final"?)
Well, Debian is a bit more complicated than it seems.

A little data -
slink AFAICT (and tentatively), released 28 August, 1999
potato released August 14th, 2000 - last revision out July 13th, 2002
woody released 19th of July, 2002

These are the last three stable releases, and have between the intervals
of 1 to almost 2 years.

Note however that stable is recommended for new users and production
servers.

The "Testing" release is actually very stable, and is used by many
(most?) experienced Debian users. Testing isn't "released" - get things
shoved into it from unstable all the time, except when the time for a
new Stable is getting near. Then testing becomes progressively quieter,
in the later phases only fixes to the RC (release critical) bugs get
accepted.

Note that unstable accepts practically anything (though Debian policy
still applies to it), any time of the year.

Each user, in turn, decides which release type he wants to track, and
occaisonally initiates "apt-get update; apt-get upgrade" commands to
synchronize that releases current state into his system.

Some features Debian has we don't -
- Releases and policy govern everything that's in a release, whether in
base or not. Our "official" means a quite specific bunch of things that
happened to be in the image the day SqueakMap came unto the scene, and
is planned to shrink. 
- The have a clear quality policy, which is pretty much applied. Even
stuff in our image is quite inconsistent in quality. If anyone thinks
I'm putting anyone down unfairly here, I'll point you to MailNotifier, a
completely broken Morph subclass that I put in there a year or more
back. Obviously, we could have better mechanism for this.
- Quite a bit of their policy is checked by automatic tools. We have
quite a bit of tools spread here and there, in the image, in the SLint,
in other tools. However, these do not benefit a systematic treatment of
quality in any way - there's no page describing the QA tools, and I
think they could get much more use.
- Debian Packages can be separately moved into and bounced out of
testing at any time. Undoing an update in the update stream is not
equivalent, as evidenced by our reluctance to put things there in the
first place. This is a good reason to move towards a harvesting tool
that let's update to different packages be listed separately, and
combines package updates from SM with code updates.

Daniel

> > - What are the rules for licenses? Should core packages be available
> > under Squeak-L? (my view)
> 
> For the short term, I agree that we should stick with Squeak-L for core
> packages.  For the long term, I wonder if we might end up wanting to allow
> other licenses, but they would have to be "Squeak-approved" licenses, in the
> same way that Debian has Debian-approved licenses.  Or maybe not, but it's a
> thought. :-)
> 
> > - Should we have other rules? For example, should core packages be
> > forced to include unit tests? (my view, and we need to create tests for
> > packages that don't have them)
> 
> I'd say probably yes, eventually.
> 
> - Doug Way
>