[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#252928: Why did you lower the severity of #252928?

package kdelibs4
severity 252928 important

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:

   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.
   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.
   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.
   a bug which has a major effect on the usability of a package,
   without rendering it completely unusable to everyone.
   the default value, applicable to most bugs.

as you can see on

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.


Reply to: