package kdelibs4 severity 252928 important thanks Adrian Bunk writes:
>> > I described in my bugreport how this issue might cause future >> > breakage in sarge, and the simple workaround via a conflict would >> > be easy to implement. >> >> First, why don't you read the definitions of the severity levels ? >> How in the world does this make the kdelibs4 package "mostly >> unusable" ? > kdelibs from unstable + apollon from -> apollon doesn't work Yes, as I said, this does not at all make the *kdelibs* package *"mostly unusable"*. > It's definitely RC The Debian BTS severities are not about whatever definition you attach to the idea of being RC or not, they are about: critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. serious is a severe violation of Debian policy (that is, it violates a "must" or "required" directive), or, in the package maintainer's opinion, makes the package unsuitable for release. important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. normal the default value, applicable to most bugs. as you can see on http://www.debian.org/Bugs/Developer.en-gb.html#severities Clearly, the highest severity that this bug can arguably qualify for is "serious" if and only if Chris Cheney thinks so, and important otherwise. Chris has clearly shown that he did not at the time think so, so I am downgrading this bug to important. It's up to him to change it to serious if he thinks it deserves that. I hope we can now stop playing pingpong with the severity ? > In the sense "must be fixed, before the new kdelibs enters testing, > or apollon in testing will be broken". The only thing that's keeping the new apollon ( which, according to its changelog has the real fix for the problem ) from entering testing is its dependency on kdelibs. Thus, there is little chance that the new kdelibs would enter sarge and the new apollon wouldn't. >> Second, I don't understand either why you seem to think this is a >> kdelibs bug and not an apollon one ? I'm reassigning to apollon. > I don't know who's at fault, but no matter who's fault it is, a > conflict in kdelibs is needed. For people using strange combinations of testing and unstable, I agree that a conflict would be useful, but I don't consider this release critical at all, for the reason stated above. And even if I did, it wouldn't matter at all, read the f****n definitions of the severity levels, please. > No change in apollon can prevent the breakage of apollon in testing > if a new kdelibs enters testing before a new apollon. True, but this situation will be fixed immediately when the new apollon enters testing as well. The only thing that's keeping it from doing that is its dependency on kdelibs4. Thus, when kdelibs4 will enter testing, so will apollon. cheers domi
