Hi. Please do not cc me. I read the list. Thanks.
Art Edwards wrote: > Chris Metzler wrote: >> >> Hm, well, I understand that you're having a problem, but I don't really >> see it as a problem with testing, or that testing is broken; but rather, >> it seems more like a problem with the idea that stuff like this won't >> happen with testing. In fact, this kind of thing tends to happen quite >> frequently in testing, when testing is far from a planned release as >> stable. It's in the nature of what testing is. Wait for a while and >> it'll sort itself out. If you don't wanna wait a while, stable or >> unstable are for you. Testing is not offered up as a robust distribution, >> and never has been; it's an automated collection of packages drawn from >> unstable that are considered releasable due to certain criteria. >> Sometimes stuff gets by the scripts. Last year, there were extended >> periods where GNOME and KDE were uninstallable out of testing (in KDE's >> case, I'm pretty sure it lasted months). Only after a pre-release >> freeze goes in should testing be considered robust enough to complain >> about stuff like this happening. > > I have to say that during the time between Woody and Sarge (a long time) > people were encouraged to use testing as a nearly stable platform. By whom? Sure, at various times, various people suggest various things. But I've never seen anything official from the Debian project encouraging users impatient for more current releases of packages to run testing. > Without it, Debian may have been abandoned by a significant part of its > user base. Isn't testing like a beta-test distribution? No, it isn't. And it's frustrating how often that misconception comes up here, because what testing is and is not is explained very well in the Debian documentation (see, for instance, http://www.debian.org/devel/testing ) and in a kajillion threads in the archives of this mailing list (see, for instance, http://lists.debian.org/debian-user/2003/07/msg00615.html http://lists.debian.org/debian-user/2003/07/msg00693.html ). That said, the current version of the Debian Reference is unfortunately misleading on this topic (Osamu Aoki, are you around?). When a package has spent "enough" time in unstable (how much is enough depends on the package/upload, but is a formally defined amount of time, not an arbitrary thing) without any release-critical bugs, and if that package's dependencies are in testing, the package is moved automatically (that is, by scripts rather than by humans) to testing. It's a set of packages that's collected in an automated fashion. The hope is that at all times it'll be releaseable, or nearly-so. But the reality is sometimes stuff in testing is badly broken, and stays that way for months. Last year, for instance, some KDE libraries came down to testing at one point; they had no bugs, and all of their dependencies were present. But that broke most of the KDE packages that depended on them, and those packages couldn't be updated because they also depended on a library that *did* have a release-critical bug on it (and thus couldn't come down to testing). So KDE was uninstallable in testing, and stayed that way for *months*. When testing is far from release, that kind of thing can happen. But it's not a problem with testing -- it's a problem with the expectation that testing is always going to be a robust release. > If this is its > intended pupose, wouldn't it be a good idea to try to assure that large > scale problems are kept to a minimum? No, because that isn't its intended purpose. Running testing and reporting problems in it, particularly as the freeze approaches or has arrived, is a good way to contribute to the project. But make no mistake that there's likely to be lots of problems when testing is far from release. It's the nature of the distribution. (and that's without even getting into the subject that testing does not get direct security updates. Stable does. Unstable effectively gets them through uploads. Testing doesn't get them until the packages trickle down from unstable, which could take a long while depending on the situation. So running testing requires *a lot* more effort on keeping up to date with security issues.) -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
