* Re: Confirming a bug in new bugzilla? [not found] ` <AANLkTimOy+Vqu9VW0RY+FL6N+8CZw0HTxWCO72Z_qQJc@mail.gmail.com> @ 2011-04-09 19:51 ` Gerald Pfeifer 2011-04-10 0:19 ` Joseph S. Myers 0 siblings, 1 reply; 6+ messages in thread From: Gerald Pfeifer @ 2011-04-09 19:51 UTC (permalink / raw) To: Manuel López-Ibáñez, Frédéric Buclin Cc: Steve Kargl, Jakub Jelinek, gcc, gcc-patches [-- 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confirming a bug in new bugzilla? 2011-04-09 19:51 ` Confirming a bug in new bugzilla? Gerald Pfeifer @ 2011-04-10 0:19 ` Joseph S. Myers 2011-04-10 22:51 ` Frédéric Buclin 0 siblings, 1 reply; 6+ messages in thread From: Joseph S. Myers @ 2011-04-10 0:19 UTC (permalink / raw) To: Gerald Pfeifer Cc: Manuel López-Ibáñez, Frédéric Buclin, Steve Kargl, Jakub Jelinek, gcc, gcc-patches 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). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confirming a bug in new bugzilla? 2011-04-10 0:19 ` Joseph S. Myers @ 2011-04-10 22:51 ` Frédéric Buclin 2011-04-10 23:33 ` Jonathan Wakely 2011-04-11 0:03 ` Joseph S. Myers 0 siblings, 2 replies; 6+ messages in thread From: Frédéric Buclin @ 2011-04-10 22:51 UTC (permalink / raw) To: Joseph S. Myers Cc: Gerald Pfeifer, Manuel López-Ibáñez, Steve Kargl, Jakub Jelinek, gcc, gcc-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confirming a bug in new bugzilla? 2011-04-10 22:51 ` Frédéric Buclin @ 2011-04-10 23:33 ` Jonathan Wakely 2011-04-10 23:42 ` Frédéric Buclin 2011-04-11 0:03 ` Joseph S. Myers 1 sibling, 1 reply; 6+ messages in thread From: Jonathan Wakely @ 2011-04-10 23:33 UTC (permalink / raw) To: LpSolit Cc: Joseph S. Myers, Gerald Pfeifer, Manuel López-Ibáñez, Steve Kargl, Jakub Jelinek, gcc, gcc-patches 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confirming a bug in new bugzilla? 2011-04-10 23:33 ` Jonathan Wakely @ 2011-04-10 23:42 ` Frédéric Buclin 0 siblings, 0 replies; 6+ messages in thread From: Frédéric Buclin @ 2011-04-10 23:42 UTC (permalink / raw) To: Jonathan Wakely Cc: Joseph S. Myers, Gerald Pfeifer, Manuel López-Ibáñez, Steve Kargl, Jakub Jelinek, gcc, gcc-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confirming a bug in new bugzilla? 2011-04-10 22:51 ` Frédéric Buclin 2011-04-10 23:33 ` Jonathan Wakely @ 2011-04-11 0:03 ` Joseph S. Myers 1 sibling, 0 replies; 6+ messages in thread From: Joseph S. Myers @ 2011-04-11 0:03 UTC (permalink / raw) To: Frédéric Buclin Cc: Gerald Pfeifer, Manuel López-Ibáñez, Steve Kargl, Jakub Jelinek, gcc, gcc-patches [-- Attachment #1: Type: TEXT/PLAIN, Size: 1150 bytes --] 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. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-04-11 0:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20100925054454.GA81084@troutmask.apl.washington.edu>
[not found] ` <20100925084632.GK2652@sunsite.ms.mff.cuni.cz>
[not found] ` <20100925142844.GB83390@troutmask.apl.washington.edu>
[not found] ` <AANLkTimOy+Vqu9VW0RY+FL6N+8CZw0HTxWCO72Z_qQJc@mail.gmail.com>
2011-04-09 19:51 ` Confirming a bug in new bugzilla? Gerald Pfeifer
2011-04-10 0:19 ` Joseph S. Myers
2011-04-10 22:51 ` Frédéric Buclin
2011-04-10 23:33 ` Jonathan Wakely
2011-04-10 23:42 ` Frédéric Buclin
2011-04-11 0:03 ` Joseph S. Myers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).