In <AANLkTimBZN8d2MeKpXx6Q1sa0HOng21two0rhfKoPROE@mail.gmail.com>, Jordi Gutiérrez Hermoso wrote: >On 7 October 2010 14:06, Joachim Reichel <firstname.lastname@example.org> wrote: >> I guess what Christoph meant is the following: if you upload 1.45 to >> unstable you block this way for fixes to 1.44 in testing (and the RM will >> most probably not allow 1.45 to migrate to testing). >> >> You could upload 1.45 to experimental for now. This allows you to upload >> 1.44-2, -3, and so on which just fix RC bugs in 1.44-1, upload them to >> unstable and request a freeze exception. > >I've never really understood why Debian works like this. >In this particular case, we *know* that the >so-called "experimental" package is going to be even more stable than >the testing package, because it's had many more bugfixes tested by >upstream than tested by Debian. It seems silly to have to label it >"experimental". I disagree that *any* package based on a new upstream release is *known* to be less buggy than the existing package, even *before* it gets uploaded to unstable/experimental. (Exception: packages that have already been in a Debian derivative for some period of time before entering unstable/experimental.) >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 a bad thing; even very small fixes can inadvertently break a package for an entire architecture. (E.g. bug #595728, which isn't about t-p-u but rather the *stable* update process) >Why does experimental >become the new unstable during freeze time? Remember that the "unstable" name was chosen to indicate how often it is updated, not how well-tested the upstream software is. "unstable" is packages intended to be in the next release of Debian, as they are uploaded. If your package isn't intended for the next release of Debian, it shouldn't be in "unstable". With the freeze on, you should be fairly sure you will get a freeze exception from the release team *before* you upload to "unstable". "experimental" is packages not yet intended for any release of Debian, for whatever reason. It gets used as "unstable+1" during the freeze, since there's no better place. Having an "unstable+1" might work, but probably not; in any case, it would only be useful during a freeze AND you'd likely have to re-upload to "unstable" after the thaw anyway. (Continual automatic migration from "unstable+1" to "unstable" is wrong semantically, and likely has some technical hurdles as well.) If a re-upload is required anyway, we might as well just use "experimental" as "unstable+1" during the freeze, IMHO. -- Boyd Stephen Smith Jr. ,= ,-_-. =. email@example.com ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Description: This is a digitally signed message part.