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 have.) 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 rock. 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 unusable". *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 months. > 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.