Patchwork Confirming a bug in new bugzilla?

login
register
mail settings
Submitter Gerald Pfeifer
Date April 9, 2011, 7:51 p.m.
Message ID <alpine.LNX.2.00.1104092128530.3701@gerinyyl.fvgr>
Download mbox | patch
Permalink /patch/90484/
State New
Headers show

Comments

Gerald Pfeifer - April 9, 2011, 7:51 p.m.
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
Joseph S. Myers - April 10, 2011, 12:19 a.m.
On Sat, 9 Apr 2011, Gerald Pfeifer wrote:

> -<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>

I think this text is superior for GCC to that on the generic page and so 
we should replace the text on the generic page by this GCC-specific text.

> -<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>

Likewise.  We don't use VERIFIED and CLOSED in GCC, proper text should 
reflect the existence of only one closed state with a genuine meaning and 
not mention the others (ideally they'd be completely hidden).
Frédéric Buclin - April 10, 2011, 10:51 p.m.
Le 10. 04. 11 02:19, Joseph S. Myers a écrit :
> Likewise.  We don't use VERIFIED and CLOSED in GCC, proper text should 
> reflect the existence of only one closed state with a genuine meaning and 
> not mention the others (ideally they'd be completely hidden).

That's not true. VERIFIED and CLOSED are valid bug statuses used in the
GCC Bugzilla. There are 517 bugs with one of these statuses.

In reply to Gerald, Bugzilla 4.2 will contain a hook which will let us
easily customize the http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html
page. For now, if changes are wanted on this page, a bug should be filed
in GCC Bugzilla (please CC me) and the template modified via a patch.
The patch will have to be backed out before we upgrade to 4.2.

Frédéric
Jonathan Wakely - April 10, 2011, 11:33 p.m.
On 10 April 2011 23:51, Frédéric Buclin wrote:
> Le 10. 04. 11 02:19, Joseph S. Myers a écrit :
>> Likewise.  We don't use VERIFIED and CLOSED in GCC, proper text should
>> reflect the existence of only one closed state with a genuine meaning and
>> not mention the others (ideally they'd be completely hidden).
>
> That's not true. VERIFIED and CLOSED are valid bug statuses used in the
> GCC Bugzilla. There are 517 bugs with one of these statuses.

Most of those cases are the reporter changing the status to VERIFIED
after a gcc maintainer has set it to RESOLVED.  That doesn't mean the
maintainers use VERIFIED of that keeping it is useful.
Frédéric Buclin - April 10, 2011, 11:39 p.m.
Le 11. 04. 11 01:33, Jonathan Wakely a écrit :
> Most of those cases are the reporter changing the status to VERIFIED
> after a gcc maintainer has set it to RESOLVED.  That doesn't mean the
> maintainers use VERIFIED of that keeping it is useful.

If they are useless, then they should be removed to avoid confusion and
to make queries easier. But if we keep them, then they should be
described as any other bug status. An external user cannot guess that
they have no special meaning for you.

Frédéric
Joseph S. Myers - April 11, 2011, 12:03 a.m.
On Mon, 11 Apr 2011, Frédéric Buclin wrote:

> Le 10. 04. 11 02:19, Joseph S. Myers a écrit :
> > Likewise.  We don't use VERIFIED and CLOSED in GCC, proper text should 
> > reflect the existence of only one closed state with a genuine meaning and 
> > not mention the others (ideally they'd be completely hidden).
> 
> That's not true. VERIFIED and CLOSED are valid bug statuses used in the
> GCC Bugzilla. There are 517 bugs with one of these statuses.

They are not *meaningful* statuses.  The standard Bugzilla descriptions 
are written in terms of a QA setup that simply does not exist for GCC and 
there is no GCC-specific policy, written or unwritten, for these statuses.

The standard "ASSIGNED" description is another one that does not fit well 
with GCC; the meaning is supposed to be that the assignee is working on a 
fix ("the proper person" is not a meaningful concept here), and the normal 
return to NEW is not "given to another person" but the assignee admitting 
they are no longer working on a fix and removing themselves as assignee 
without adding someone else.

Patch

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>