Suggestion for a new GNATS policy

[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