Bugzilla - an experiment in trackability
Brad Roberts
braddr at puremagic.com
Sun Mar 5 15:09:55 PST 2006
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
More information about the Digitalmars-d-bugs
mailing list