Bug#252928: Why did you lower the severity of #252928?
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
Reply to: