Re: severity changes post-release

[Luis Villa <louie ximian com>]

On Sun, 2002-06-09 at 00:36, Malcolm Tredinnick wrote:
> On Fri, Jun 07, 2002 at 09:08:49AM -0400, Luis Villa wrote:
> > Something I've been thinking about for a while... after release, I'd
> > like to rename 'critical' to 'crasher' and 'trivial' to 'cosmetic' to
> > make it slightly more clear to first time users (esp. via bug-buddy)
> > where to place those kinds of bugs. 
> 
> 'trivial' -> 'cosmetic' sounds fine, but I'm not sure about the first
> one.
> 
> I guess this whole mail comes down to the fact that we need to collect
> examples of what types of bugs are what. I guess all your GNOME 2
> tracking experience makes you the best one to generate the initial ideas
> there, Luis, since although, for example, I could make up some stuff, I
> only look at bugs in a limited number of categories and my ideas are
> possibly out of touch with others' versions of reality.

Well, there are already definitions of types of bugs listed at 

http://bugzilla.gnome.org/bug_status.html#severity

Given that those definitions have worked pretty well, I'd like to make
the tags given to them map more cleanly, which is what the
critical->crasher switch is about. I've seen that users are reluctant to
mark crashers (or anything) as critical; changing that to 'crasher'
makes it easier for them to get the categorization right on the first
count. 

> > Less concretely: I'd also definitely like to make 'blocker' more clear
> > (since it implies things that just aren't true) but I'm not quite sure
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    Can you clarify this a bit? For example...?

The important example is that 'blocker' implies it blocks a release. And
it doesn't/shouldn't. Immediate/Urgent should. 

> I would like clearer titles (or clearer descriptions of what the
> categories mean). I think your "blocker" example leaves out a case,
> though. Surely one bug "blocks" another if it's just a normal bug (not a
> build problem or a security problem) that has to be fixed before the
> second one can be fixed. 

That's what bug dependencies are for. The original definition of blocker
was intended to imply that it blocked release, not that it blocked other
bugs. 

> Using blockers and "depends upon" lists in this fashion helps to order
> the process, so I think it would be a shame to narrow blocker to not
> include that. 

Blocker has never included that.

> Surely, a blocker is just that .. it essentially blocks
> the release for whatever reason and major non-security bugs can do that.

That's what we've been using urgent/immediate for, not blocker, and I
believe that that is a more correct procedure. That is why we have
distinct priority and severity fields; removing 'blocker' makes the
distinction between the two much more clear.

Luis