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