Bugzilla - an experiment in trackability

[Brad Roberts]

On Sun, 5 Mar 2006, Walter Bright wrote:

> Priority:
> 
> P1: so bad that an update needs to happen immediately; i.e. it makes D 
> unusable
> P2: fold into next update; things that break existing code go here
> P3: should get around to fixing sooner or later
> P4: defer until next major version
> P5: informational; nobody really cares

I'll add these to the page you see when you click on the Priority link 
when entering a bug.  I tend to think of priority as something that you as 
the author should be setting.

> Severity:
> 
> blocker - prevents use of a major component of D, such as phobos
> critical - silent generation of bad code
> major - produces compiler crash or generation of internal error messages
> normal - garden variety bugs
> minor - easy workaround
> trivial - only of interest to compiler validation test suites
> enhancement - change to documented behavior

I tend to think of severity as something the submitter sets, though it can 
be adjusted certainly.

IMHO, Severity should be tempered by the nature of the bug.  If it's a 
crash of the compiler on invalid code that is less severe than a crash on 
valid code.

Some of your descriptions above touch on another area of classification 
that fits into what bugzilla calls keywords. I've copied the same keywords 
that the gcc crew use.  Click on the keywords link when submitting a bug 
to see the list.

I can update the docs to list the above descriptions, but before I do, 
here's the current descriptions.  Think a little about this before I go 
and change them.

Blocker     Blocks development and/or testing work
Critical    crashes, loss of data, severe memory leak
Major       major loss of function
Minor       minor loss of function, or other problem where easy workaround is present
Trivial     cosmetic problem like misspelled words or misaligned text
Enhancement Request for enhancement

> > Would Walter prefer test cases entered in the description or attached as 
> > files?  I've done the former for old bugs, but it would be useful to know 
> > how to format future reports.
> 
> If the size is reasonably small, they should be in the description. 

If the test case is small and unlikely to change, I agree.  If you think 
the test case is going to evolve, an attachment is probably better since 
they can be marked obsolete making it easier to track the relevance of 
them.

Later,
Brad