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

[Adrian Bunk <bunk@fs.tum.de>]

On Fri, Jun 18, 2004 at 11:52:36PM +0200, Dominique Devriese wrote:
> Adrian Bunk writes:
> 
> > On Fri, Jun 18, 2004 at 10:29:07PM +0200, Dominique Devriese wrote:
> >> ...  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 ?
> 
> > As said in the part of the mail you skipped: Your RM reopened a
> > similar (grave) bug I sent that covered a similar issue.
> 
> > Chris uploaded a new version of kdelibs 6 days after my bug report.
> 
> > Why did he downgrade it instead of simply fixing the issue via a
> > conflict?
> 
> Probably because 
> 1 adding a conflict to a package because of a bug in another package
>   is generally the wrong thing to do, even if it may be good as a
>   workaround in this case

To quote another mail I sent to you in this thread:


<--  snip  -->

Please read the statement of your RM regarding a similar issue in
#170385 (in this case it was even clear that the bug was not in the
library).

<--  snip  -->


Is it really "the wrong thing to do" if your RM thinks a conflict is 
required in such cases?


> 2 you did not provide a lot of explanation about why it was the
>   correct thing to do in this case

It's the only way to solve this issue.

And if the it's unclear, a question might be a better solution than a 
silent lowering of 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.  ...
> 
> > Imagine a new upload of apollon to unstable, a RC bug in apollon, or
> > many other reasons like apollon not being built on one architecture.
> 
> Of course, but you have to agree that it won't take ages to fix
> something like this in a simple package like apollon.  This is where
> the difference is with the wine bug you were talking about.

It was _exactly the same situation_:
Wine in unstable was already fixed at that time.

The point of a conflict is to force an upgrade of the application at the
same time as the upgrade of the library.

> By the way, why do you seem to think that an uninstallable version of
> apollon in sarge is better than a version that crashes on startup ?

I'm not a big fan of testing, but one positive side of testing is that 
the way testing works this can't happen [1].

> cheers
> domi

cu
Adrian

[1] except for cases of manual interventions of the RM

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed