[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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@sherohman.org> 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
> stable.

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 
<http://iguanasuicide.net/node/4>.  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@iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

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

Reply to: