[vox] Sarge is frozen!
Karsten M. Self
kmself at ix.netcom.com
Tue May 3 18:17:16 PDT 2005
Ken, good overall description, a few odd notes...
on Tue, May 03, 2005 at 04:25:25PM -0700, Ken Bloom (kabloom at 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*
addressed.
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
(kfreebsd-gnu)
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
Peace.
--
Karsten M. Self <kmself at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://ns1.livepenguin.com/pipermail/vox/attachments/20050503/9d32a1ca/attachment-0001.bin
More information about the vox
mailing list