This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bugzilla'd version of our gnats database


On Fri, 21 Dec 2001, Daniel Berlin wrote:

> Sigh.
> This sucks.
> Why couldn't they use some real standardized format, or a real database?

With GNATS, each front end does the status change messages itself, in its
own way.

> > It's not pointless.  doc-bug | accepts-illegal | rejects-legal |
> > wrong-code | ice-on-legal-code| ice-on-illegal-code | pessimizes-code |
> > sw-bug | change-request | support are meaningful divisions describing
> > bugs, I don't see how they map to severities.
> I meant, literally, you can change the name to severity.
> Or i could do it the other way around (change severity to class, and add
> these divisions back).

We want something like these divisions, whatever they're called.  We do 
not want users submitting bugs to be asked for any form of opinion about 
how important a bug is or when it should be fixed (as with present 
Priority and Severity).  (Though they can always provide information that 
might influence our judgment about the importance of a bug, e.g. what 
software the testcase came from.)

I don't think that storing further information about bug importance /
priorities, beyond target milestones and the factual descriptions of type
of bug presently in Class, is of any particular use; but if other people
want to use such fields and can provide coherent documentation for what
the different values mean in a GCC context, the inclusion of such a field
or fields (set by developers only, not at bug submission) is OK by me.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]