[Top][All Lists]

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

Bug#404739: Processed: reassign 404739 to gss

From: Simon Josefsson
Subject: Bug#404739: Processed: reassign 404739 to gss
Date: Tue, 09 Jan 2007 09:07:45 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.92 (gnu/linux)

Steve Langasek <address@hidden> writes:

> On Tue, Jan 09, 2007 at 08:23:47AM +0100, Simon Josefsson wrote:
>> Russ Allbery <address@hidden> writes:
>> > We should raise the severity of the bug to grave (better than serious,
>> > since it's a usability issue, not a policy violation) and upload a new
>> > 0.0.18 version with the minimal patch.  I think the release team will be
>> > happy with that.
>> Done.
> Sorry, what's the rationale of this bug being marked as 'grave'?

If I understand Russ correctly, I believe it would be that this
problem makes the package unusable for amd64 users.  That seems
compatible with the definition for grave given at:

Although the definition of "important": "a bug which has a major
effect on the usability of a package, without rendering it completely
unusable to everyone" might suggest that if a problem renders a
package unusable only for a portion of users, it is not grave.  (If
this is the intended interpretation, I suggest that the definition of
"grave" should be modified to say "makes the package in question
unusable FOR EVERYONE, or mostly so, ...".)

I searched a little about this, and found this discussion:

That suggests to me that amd64 specific ftbfs's would warrant
"serious" severity, once the amd64 is considered for the next release.

> Has this problem been seen on any archs other than amd64, where it
> fails the testsuite and therefore generates no binaries?


> If all the archs where the package has been built have working binaries, I
> don't see any reason why this should be treated as RC, despite amd64 being
> the missing arch.

Ok.  What would you like to see happen here?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]