Daniel Vainsencher <danielv at netvision.net.il> wrote:
> 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.

This should be our long term goal for the tiny kernel!

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

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


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

Independant update cycles
-------------------------------
> - 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

Policies will surely help us. But we will have to ramp them 
up gradually. A first policy statement will probably be fairly short.



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

Yes we should have 14000 unit tests! (3000 are actually under way
already)
(14000 / 1800) asInteger  7  -> 7 tests per class if we take the current
number
of classes. But of course the kernel we are heading for will be much
smaller.

-- Hannes Hirzel