Re: What is consensus for meaning of stable/unstable? (Re: Does everything depend on everything?)

On Thursday 05 November 2009 05:24:49 Micha Feigin wrote:
On Thu, 5 Nov 2009 01:57:05 -0600
Dave Sherohman <dave@xxxxxxxxxxxxx> wrote:
On Thu, Nov 05, 2009 at 01:10:37PM +1300, Chris Bannister wrote:
On Sat, Oct 31, 2009 at 09:46:20PM +0200, Micha wrote:
My experience over the last 12 years or so is that stable, testing,
unstable talks more about how volatile the distribution is rather
than how stable it actually is.

AIUI, that _is_ the meaning. Think, stable - unchanging. esp in resp to
API's etc.

unstable - changing frequently at random.

Not to be confused with "buggy ness" or "more likely to crash" etc.

That's a false dichotomy. Every change made to a piece of software has
the potential to introduce a bug. Therefore, more volatile code is also
more likely to crash.

And from the software engineering side, every software has bugs.

It's not a bug it's a *feature*!

Also a LOT of the changes are bug fixes and security enhancement so I could
claim that newer software is likely more stable.

Crashes that can't be avoided by the user are release-critical. Security
enhancements are security-related. If someone develops a patch for such an
issue, the maintainer can backport it to the version in stable, roll a new
package, and the release team will approve it.

Stable doesn't just bit-rot as you are implying here.

Also, you are ignoring the fact that unstable is not developed by the
debian maintainers.

Some is. (But, lets talk about the ones that aren't, since those are the ones
that matter for this conversation.)

They are taking TESTED software (although not by debian
track record but by the software developers and other users) and putting it
into debian.

Given the large number of non-packaging bugs that are discovered while
software is in testing/unstable, I don't trust most upstreams to test their
software. I trust the ones I know have some sort of testing framework that
they require releases to go through (git), I trust the ones that have a large
community that pulls directly from them (Mozilla). I do trust Debian users to
file bugs, which is enough to keep major issues out of stable.

The stability is a function of the maturity of the software
you are using. If it is unstable due it being new in unstable it probably
didn't even exist in stable or was so featureless as to be unusable in

Yeah, that's completely wrong except for the newest of software. Git is
fairly new, and the version is stable is a number of releases behind, but the
version in stable is completely usable. (Yes, there are features it doesn't

The KDE 3 in Etch is completely usable compared to the KDE 3 in Lenny; the one
in Lenny is faster and has more minor bugs fixed, but both are solid as a

vim, zsh, etc., etc. You sound like you've either never used stable, or you
consider anything more than a few months old as "so featureless as to be

*I* *love* *new* *features*. I get them everytime there's a new Debian stable
release and they rarely, if ever, break on me. But I'm not willing to have my
computer demand 2-6 hours to fix a problem, even if it is just once every 2-3

Big leaps in unstable are rare, the move of X to hal is one example but it
is not often.

KDE 3 -> KDE 4
X -> X+HAL
Gnome -> Gnome-mdadm

Three things that would have broken my system in two since Lenny was released.
Lots more minor transitions. Unstable is not something I can count on not to
break; stable has a much better track record.

Stable isn't unchanging because people hate new features and want to run
a two-year-old codebase for fun, it's unchanging because those packages,
at those versions, have been tested to hell and back, both individually
and when used together, to identify and eliminate as many bugs as
possible. Testing and unstable are buggier and more likely to crash
because they haven't been as thoroughly debugged (and, indeed, they
can't be as throughly debugged because they're more volatile).

No, the bugs in stable are just know, well documented and NEVER fixed
unless they are security bugs. Ran in quite a few of these bugs and/or
missing features.

This is not true. A release-critical bug may be fixed with an update to
stable, even if it is not security related. It doesn't always happen; but the
bug must be release-critical or security-related before it's considered cause
to disrupt stable.

Even then, stable is not updated continuously as fixes are prepared. Instead
they live in proposed-updates until the next refresh date.

Yes, I've run into known bugs in stable. It's much more pleasant than running
into a new bug in testing/unstable.

Stable is not for everyone, but I do think it is better for new users. If you
are coming from Debian from another distro and you were following ~arch
(Gentoo), rawhide (Fedora), factory (openSUSE), or the equivalent elsewhere;
don't even bother with stable and just do unstable or mixed testing/unstable.
If you want newer versions of specific pieces of software in stable, take a
little time to learn how to run a mixed system, and do something like
<>. If you want the latest and greatest and
are willing to put up with constant churn, use unstable or testing/unstable,
but please file bugs -- it helps make my stable better.
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@xxxxxxxxxxxxxxxxx ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' \_/

Attachment: signature.asc
Description: This is a digitally signed message part.