This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Suggestion for a new GNATS policy
- From: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- To: gcc at gcc dot gnu dot org
- Cc: bangerth at ices dot utexas dot edu, giovannibajo at libero dot it
- Date: Sun, 11 May 2003 22:30:05 +0200 (CEST)
- Subject: Suggestion for a new GNATS policy
- Reply-to: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
There has been some effort over the last year to clean up GCC's bug database.
One problem is that many bug reports have to be revisited several times
(which is just a waste of resources), because of two problems:
1) The state "analyzed" does not help much, because the requirements are
too weak: It just means that somebody has looked at it and agrees that
there's a bug in GCC. Very often not even the class of the PR is set
correctly. Preprocessed files (especially for C++ bugs) are often huge
so that somebody who tries to fix a bug has to do major work (which
could be done by somebody else) before being able to tackle the core
of the problem.
So IMHO we need some stricter requirements for reports in state "analyzed".
Knowing that any analyzed PR is in the right class and has a simple testcase
attached and a suitable synopsis line would help the bug fixers to do their
work efficiently.
2) To close the PRs that got fixed silently the PRs have to be revisited from
time to time. But there should be some way to give the PR's a time stamp
so that one can easily see (without having to read the whole audit-trail)
when a PR should be revisited again.
To tackle both of the problems, Wolfgang Bangerth and Giovanni Bajo are
wading through the PR's to meet the requirements mentioned in 1) for each
analyzed PR (for C++ category first, but C, optimization and middle-end will
hopefully follow). And they are putting time stamps on those PRs.
In addition, I've collected quite a number of testcases that are tested
automatically almost daily so that the related PRs do not require manual
rechecking. Therefore, I want to give them a special stamp "[monitored]"
instead of a date stamp.
To keep the shape of the bug database from deteriorating again, I'd like
to formalize the strategy above by suggesting the following change to
"bugs/management.html":
===============================================================================
--- management.html Fri May 9 11:44:50 2003
+++ management.html.new Fri May 9 17:26:09 2003
@@ -105,11 +105,25 @@ some fields. The State field should be u
<dd>The PR has been filed and the responsible person(s) notified.</dd>
<dt>analyzed</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. At that time, an indication should be
-left in the report who tested the bug and when.</dd>
+<dd>A maintainer has verified that this is indeed a bug in GCC.
+All analyzed reports should
+<ul>
+<li>contain a <strong>small testcase</strong>,</li>
+<li>be in the <strong>right category and class</strong>,</li>
+<li>have a suitable <strong>synopsis</strong>,</li>
+<li>have a stamp "<strong>[... regression]</strong>" in the synopsis line
+if it is indeed a regression (see "Procedures and Policies")</strong>,</li>
+<li>have a date stamp "<strong>[YYYY-MM-DD]</strong>" in the synopsis line
+that indicates when the report was last checked.</li>
+</ul>
+Otherwise the PR should remain open.<br />
+Every once in a while, old reports will need to be rechecked, to find out
+whether the bug still exists. At that time, please bump the date in the
+synopsis line. Some reports have a stamp "<strong>[monitored]</strong>"
+instead of a date stamp in the synopsis line. This means that the PR is
+checked automatically (currently against the 3.3 branch and mainline almost
+daily by a program run by Volker Reichelt). These reports do not have to be
+rechecked manually.</dd>
<dt>feedback</dt>
<dd>The submitter was asked for further information, or asked to try
===============================================================================
The requirement of a short testcase is probably only feasible for some
categories like C++, but not for others like bootstrap.
One last remark: It's easy to decide whether a PR was analyzed according
to the new or old rules by just looking for the date stamp in the synopsis
line.
Regards,
Volker Reichelt