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: Severities and priorities in bugzilla


> Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> wrote:
> 
> >> To me, having Severity, Priority, and Milestone is still a little
> >> confusing. Is there a way to enforce that all P1 priority bugs have a
> >> milestone set?
> 
> > How about kicking Priorities completely?
> 
> Agreed, unless someone explain me (possibly with examples) the situations
> where we should set Critical+P3 or Minor+P1 (the corner cases). I think
> priority and severity are kind of overloaded concepts for many people
> (including myself). My idea was that for instance we could use Critical+P3
> for a bug where GCC formats your hard disk if (and only if) the input file
> is made of exactly 12345678 zeros plus a newline, and Minor+P1 if all the
> warning line numbers are off by one, but after a while I realized that there
> is so need for such a strict separation of concepts.
> 

You're confusing the two categories.  One is a measure of impact on the 
USER.  The other is the perceived importance to GCC maintainers.

As I see it, a critical bug is one that prevents a USER from using the 
compiler in some way.  However, if it has always been broken, then we 
might give it a P3 priority.  An example would be someone who needs to 
compile some c99 code that uses identifiers in the extended character set. 
 It doesn't work, so it's critical to them.  But it isn't high on our list 
of priorities at this time, so it's P3 to us.

R.


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