[Top][All Lists]

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

[Gnash-dev] Re: Definition of "blocker" bug severity

From: Petter Reinholdtsen
Subject: [Gnash-dev] Re: Definition of "blocker" bug severity
Date: Mon, 20 Dec 2010 19:24:50 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

[Sandro Santilli]
> Due to recent discussion with Rob, this mail is
> to get a shared interpretation of the Severity 
> field we have for bugs:

The severity descriptions I am most familiar with is the Debian one,
available from <URL: >.
Some of these map directly to those.

> 1. Wish

          for any feature request, and also for any bugs that are very
          difficult to fix due to major design considerations.

> 2. Minor

          a problem which doesn't affect the package's usefulness, and is
          presumably trivial to fix.

> 3. Normal

          the default value, applicable to most bugs.

> 4. Important

          a bug which has a major effect on the usability of a package,
          without rendering it completely unusable to everyone.

> 5. Blocker

          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 (roughly, it violates
          a "must" or "required" directive), or, in the package
          maintainer's or release manager's opinion, makes the package
          unsuitable for release.

> 6. Security

In Debian the security status is a tag and not a severity, so it can
be attached to any bug.

> "Blocker" I've used mostly to mean "release blocker", that is
> something you should fix before next release.

I assume you mean 'must fix' here.  For me a blocking bug would be one
that need to be fixed before the next release too, but because it make
the package almost unusable or break other packages, or because the
package maintainer believe the bug make it unfit for release.

> "Important" is something people will be likely to complain a lot
> about (say support for latest YouTube change).

Given that some people will complain about anything, this seem like a
bad way to decide if the bug should get severity important or not.  I
would suggest using the Debian definition instead.

Happy hacking,
Petter Reinholdtsen

reply via email to

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