l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2005 May 04 02:08

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] Sarge is frozen!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] Sarge is frozen!

Ken, good overall description, a few odd notes...

on Tue, May 03, 2005 at 04:25:25PM -0700, Ken Bloom (kabloom@ucdavis.edu) wrote:
> Bob Scofield wrote:
> > On Tuesday 03 May 2005 13:52, Bill Kendrick wrote:
> >
> >>"Sarge is now frozen!   Wheeeeeee!!!"
> >>
> >>
> >>
> >>They're shooting for a release date of May 30th.
> >
> >
> > Okay, since I'm new to Debian I guess I can ask this question.  What
> > does "release" mean.  I've got Sarge and I download updates/upgrades
> > *every day*.  So does this May 30th release have any meaning for me?
> > My guess is that it does not.  I'm guessing that this means that if
> > someone downloads Sarge after the release he or she gets the whole
> > system, right?  And Sarge becomes "stable" then, is that right?

Understand too what the difference between release levels is:

  - Stable:  no changes, other than bugfixes and security updates.  This
    will be maintained (by the Debian security team & developers) until
    the next release date, and generally (and based on history), another
    18 months or so afterward.

    Stable is of particular interest to those who want to deploy a,
    well, stable system:  no drastic changes.  It's also somewhat useful
    to those who want to base a product on a given functionality set.
    This is particularly of interest if you're 

    The upshot is, of course, new stuff doesn't make it into stable, in
    terms of updated or newly released packages.  There are offical
    exceptions (sometime a security update mandates a package upgrade),
    and there are unofficial "backports" packages available.  For many
    desktop users, though, 'stable' tends to be a tad crufty, especially
    late in the release cycle.  That is:  now.  For VARs, stable is a
    bit of a mixed blessing as it also ships with an old kernel (and
    hence limited HW support), though this is really *trivially*

    Another somewhat curious aspect of GNU/Linux systems is this:  you
    tend to get most of your software via your distro, unlike
    proprietary OSs.  Which means that on stable, your entire system
    remains somewhat frozen in time.  While a legacy MS Windows OS
    that's five years old will generally accept new software without too
    much grumbling, doing the same on GNU/Linux can be ... interesting.

  - Unstable:  As Ken said, new and updated packages continuously enter
    unstable.  You're very likely to see major functionality changes
    over the course of an unstable cycle, release-to-release.  For
    self-supporting desktop, home, and small office users, this is an
    acceptable tradeoff for having access to the latest'n'greatest.  For
    server deployments and larger institutions, the upgrade, training,
    and compatibility issues raised may be less desireable.  Though of
    course, this being GNU/Linux and Free Software, you've got a choice.

  - Testing:  Meant to address some issues of unstable (namely:  broken
    packages), but raising a few of its own.  Testing == unstable + 10
    days  -  major bugs.  That is:  a package won't enter testing
    (barring special exemptions, generally critical bug/security fixes)
    until it's been released for ten days, and only if no major bugs are
    filed on it.  
    The problem is that when a bug _does_ occur after the ten-day mark,
    the fix itself may be delayed by ten or more days.  may not be.
    This leads to many debates over whether 'testing' or 'unstable' is
    actually the better release level.  
    Fortunately, again, this is Free Software, and you've got choices.
    A feature called 'pinning' allows specifying multiple release levels
    _and_ a priority level.  My own systems are a mix of
    testing/unstable, pinned to testing.  For critical bugs, though, I
    can immediately pull in packages from unstable.  In practice, this
    happens very rarely.

The release schedule is officially "when it's ready", and tends to
revolve around:

  - Installer:  a single, multi-platform installer that works
    successfully on all architectures.

  - RC bugs:  Anything that keeps a package from being installable,
    usable, violates Debian Policy, or prevents a smooth upgrade from
    the prior stable version.

  - Arches:  Debian runs on a multitude of architectures ("arches",
    "platforms", or "chips", or sometimes, alternate kernels).  Fifteen
    at current count.  These are:

    - Released ports: Intel x86 / IA-32 (i386), Motorola 68k (m68k), Sun
      SPARC (sparc), Alpha (alpha), Motorola/IBM PowerPC (powerpc), ARM
      (arm), MIPS CPUs (mips and mipsel), HP PA-RISC (hppa), IA-64
      (ia64), S/390 (s390)

    - Unreleased ports: AMD64, SuperH (sh)

    - Non-GNU/Linux ports: Debian GNU/Hurd (hurd-i386), Debian
      GNU/NetBSD (netbsd-i386 and netbsd-alpha), Debian GNU/kFreeBSD

    See: http://www.debian.org/ports/

Both the installer and architecture (in particular ARM, for which both
Debian Project 'buildd' or compiler machines failed) have been
significant roadblocks to release.

>                  August 2002          May 2005
>                       |                  |
> unstable  (sid) -----------> (sid) ------------> (sid)
> testing   (woody) ---\---->(sarge) ----\-------> (etch)
> stable    (potato)    \---> (woody)     \------> (sarge)

For historical release dates:

    0.93R6          Oct 26, 1995    
    1.1 ``buzz''    Jun 17, 1996   9 months 
    1.2 ``rex''     Dec 12, 1996   6 months 
    1.3 ``bo''      Jun  5, 1997   6 months 
    2.0 ``hamm''    Jul 24, 1998   13 months
    2.1 ``slink''   Mar  9, 1999   9 months 
    2.2 ``potato''  Aug 15, 2000   17 months 
    3.0 ``woody''   Jul 19, 2002   23 months 
    3.1 ``sarge''  ?Jun ??, 2005?  36 months


Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Bush:  All we have to sell is fear itself.

Attachment: signature.asc
Description: Digital signature

vox mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.