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>
