Re: Confirming a bug in new bugzilla?

[Gerald Pfeifer <gerald@pfeifer.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4798 bytes --]

On Sat, 25 Sep 2010, Manuel López-Ibáñez wrote:
> All the status have well-defined meanings:
> 
> http://gcc.gnu.org/bugs/management.html
> 
> Unfortunately, there is some duplication:
> 
> http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html

Quite some duplication, in fact.  By virtue of the patch below I am 
consolidating a significant portion thereof, leaving the instance
provided by Bugzilla (which is also used for help links provided by
the Bugzilla user interface) in place and shortening our local page.


Two concrete items remain open:

A. Status WAITING and SUSPENDED are not yet described in the Bugzilla 
description of the fields even though our Bugzilla instances provides 
them.

They should be moved there, and I'll be happy to take pointers on how
to best update this (in a way that the next Bugzilla version update does
not kill those changes).


B. Severity and Priority need to be consolidated, both in terms of
documentation and since, so far, we had not described Trivial and 
Blocker in GCC.  Alas, they are being used.  Fun, fun, fun.  

I guess the best approach is to slightly tweak the text we have in
Bugzilla, and similar to the patch below the remove it from the 
bugs/management.html page.


Frédéric, do you have any advice?

Gerald


Index: bugs/management.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v
retrieving revision 1.28
diff -u -r1.28 management.html
--- bugs/management.html	31 Dec 2010 14:49:31 -0000	1.28
+++ bugs/management.html	9 Apr 2011 19:28:50 -0000
@@ -55,29 +55,12 @@
 <p>Bugzilla offers a number of different fields.  From a maintainer's
 perspective, these are the relevant ones and what their values mean:</p>
 
-<table border="1" cellpadding="4" summary="States">
-
-<tr align="center">
-<th><h3 id="status">Status</h3></th>
-<th><h3 id="resolution">Resolution</h3></th>
-</tr>
-
-<tr valign="top">
-<td>The <em>status</em> field indicates the general health of a bug. Only
-certain status transitions are allowed.</td>
-<td>The <em>resolution</em> field indicates what happened to this bug.</td>
-</tr>
-
-<tr valign="top"><td>
+The status and resolution fields define and track the life cycle of a
+bug.  In addition to their <a
+href="http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html">regular
+descriptions</a>, we also use two adition status values:
 
 <dl>
-<dt><b>UNCONFIRMED</b></dt>
-<dd>The PR has been filed and the responsible person(s) notified.</dd>
-
-<dt><b>NEW</b></dt>
-<dd>A maintainer has verified that this is indeed a bug in GCC. Every
-once in a while, old reports will need to be rechecked, to find out
-whether the bug still exists.</dd>
 
 <dt><b>WAITING</b></dt>
 <dd>The submitter was asked for further information, or asked to try
@@ -91,60 +74,8 @@
 sought. If the problem cannot be solved at all, it should be closed
 rather than suspended.</dd>
 
-<dt><b>ASSIGNED</b></dt>
-<dd>This bug is not yet resolved, but is assigned to the proper
-person. From here bugs can be given to another person and become
-<b>NEW</b>, or resolved and become <b>RESOLVED</b>.</dd>
-     
-<dt><b>REOPENED</b></dt>
-<dd>This bug was once resolved, but the resolution was deemed
-incorrect.  For example, a <b>WORKSFORME</b> bug is
-<b>REOPENED</b> when more information shows up and the bug is now
-reproducible.  From here bugs are either marked <b>ASSIGNED</b>
-or <b>RESOLVED</b>.</dd>
-</dl>
-</td>
-
-<td>
-No resolution yet. All bugs which are in one of these "open" states
-have the resolution set to blank. All other bugs
-will be marked with one of the following resolutions.
-</td>
-</tr>
-
-<tr valign="top"><td>
-<dl>
-<dt><b>RESOLVED</b></dt>
-<dd> A resolution has been found for this bug. The bug is either closed
-for good, or can be re-opened and change to <b>REOPENED</b>.</dd>
-
 </dl>
-</td>
-<td>
-<dl>
-<dt><b>FIXED</b></dt>
-<dd> A fix for this bug is checked into the tree and tested.</dd>
-
-<dt><b>INVALID</b></dt>
-<dd> The problem described is not a bug.</dd> 
 
-<dt><b>WONTFIX</b></dt>
-<dd> The problem described is a bug which will never be fixed.</dd>
-
-<dt><b>DUPLICATE</b></dt>
-<dd> The problem is a duplicate of an existing bug. Marking a bug
-duplicate requires the bug# of the duplicating bug and will at
-least put that bug number in the description field.</dd>
-     
-<dt><b>WORKSFORME</b></dt>
-<dd> All attempts at reproducing this bug were futile, reading the
-code produces no clues as to why this behavior would occur. If
-more information appears later, please re-assign the bug, for
-now, file it.</dd>
-</dl>
-</td>
-</tr>
-</table>
 
 <p>The following two fields describe how serious a bug is from a user's
 perspective (severity) and which priority we assign to it in fixing it:</p>