In <[🔎] AANLkTikwokFFMTyFHi-YY7J=_FX8_44wbCbU3VCC6Jxs@mail.gmail.com>, Jordi Gutiérrez Hermoso wrote: >On 11 October 2010 12:11, Boyd Stephen Smith Jr. <bss@iguanasuicide.net> wrote: >>> In <[🔎] AANLkTimBZN8d2MeKpXx6Q1sa0HOng21two0rhfKoPROE@mail.gmail.com>, Jordi >>> Gutiérrez Hermoso wrote: >>>Does it have to be this way? Why do fixes to testing have to go >>>through unstable, even during freeze time? >>> >> They don't. t-p-u exists for when the version in testing needs a fix, but >> migrating the package from unstable is troublesome. It is rather frowned >> upon though, since it means the update does not get the level of exposure >> that other updates receive. > >That's what I really don't get. So testing isn't for testing, unstable >is for testing, and experimental is for unstable? So where do really >crazy ideas go? Why do all the distros get pushed back one during >freeze time? Testing *is* for testing. However, testing is not as unstable as unstable. The reason for this is simple: You can't test the functionality of a package if you can't install it. It is relatively easy for an upload to unstable to render at least one package uninstallable in unstable. The automated migration process is responsible for keeping all packages in testing installable. I hope that shows why testing and unstable have to be different versions. Since they need to be separated anyway, adding the 10-day (or so) grace period for major bugs to be identified before entering testing, allows testing be be much closer to the ideal. "Packages are installed into the `testing' directory after they have undergone some degree of testing in unstable. "They must be in sync on all architectures where they have been built and mustn't have dependencies that make them uninstallable; they also have to have fewer release-critical bugs than the versions currently in testing. This way, we hope that `testing' is always close to being a release candidate." <http://www.debian.org/doc/FAQ/ch-ftparchives> >> Remember that the "unstable" name was chosen to indicate how often it is >> updated, not how well-tested the upstream software is. > >Is that true? I've never seen an official reaffirmation of this >oft-quoted idea, it merely seems to come from people who don't mind >debugging or living with the bugs in unstable and therefore it's >"stable enough for me". "The `unstable' directory contains a snapshot of the current development system. Users are welcome to use and test these packages, but are warned about their state of readiness. The advantage of using the unstable distribution is that you are always up-to-date with the latest in GNU/Linux software industry, but if it breaks: you get to keep both parts :-)" <http://www.debian.org/doc/FAQ/ch-ftparchives> Some upstream projects do a lot of testing on their side and work closely with the Debian maintainer(s). When that is true, the package that gets uploaded to unstable is often less buggy than the package in testing (or even stable). >"The kid who breaks toys" doesn't sound to me >like "the kid who changes too much". Unstable is too buggy for me. The sid name predates the current division of stable/testing/unstable. <http://www.debian.org/doc/FAQ/footnotes.en.html#f2> >During freeze time, shouldn't bugs should be fixed in testing, not in >unstable? You freeze a distribution, you fix its bugs, and you release >it, and while the six-month freeze is in effect, you can also have >your broken toys playground if you want it. The freeze process is as you describe. What you don't seem to get is: The preferred way to fix bugs in testing to via automatic migration from unstable. This is to ensure a minimum quality of testing, so that users there can focus on testing packages, rather than suffering through breakages that the automated process can prevent. If a bug fix is high-quality, it won't have any issues passing the automated tests; if the bug fix is important, the urgency of the upload can be changed which reduces waiting time in unstable. In fact, if there are more automated tests you can think of, it wouldn't be bad for the bar between testing and unstable to be higher. I think CUT (constantly usable testing) is actually pretty close to reality once the system is installed; though, d-i and installer media are important, too. >> "unstable" is packages intended to be in the next release of Debian, as >> they are uploaded. > >Where "next" in this instance means "current"? What does >"experimental" mean, then? No. The next release of Debian is codenamed "squeeze". No release date has been set, but we are in the pre-release freeze. <http://www.debian.org/releases/> >> "experimental" is packages not yet intended for any release of Debian, > >But that's now how it's used. It's used as "not squeeze, but almost >certainly wheezy" "Experimental is used for packages which are still being developed, and with a high risk of breaking your system. It's used by developers who'd like to study and test bleeding edge software. Users shouldn't be using packages from here, because they can be dangerous and harmful even for the most experienced people." <http://www.debian.org/doc/FAQ/ch-ftparchives> Given the average time between releases of Debian, and the confidence of the "average" programmer, they will always think "if not $debrel, then $debrel+1". But what they really mean is "not ready for any release, but I should be able to make changes and upload a different package before we pass another release". >> It gets used as "unstable+1" during the freeze, since there's no better >> place. > >So why not create a better place? Because of the limited utility, which I mentioned in the message to which you replied. First, it only has any use during a freeze. Second, you'd probably have to upload to unstable after the thaw anyway. -- 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.