This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suggestion for a new GNATS policy
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- Cc: gcc at gcc dot gnu dot org,bangerth at ices dot utexas dot edu,giovannibajo at libero dot it
- Date: Sun, 11 May 2003 16:46:45 -0400
- Subject: Re: Suggestion for a new GNATS policy
On Sunday, May 11, 2003, at 04:30 PM, Volker Reichelt wrote:
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.
Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED" if
assigned to someone, "NEW" otherwise).
Remember we are moving to Bugzilla rather soon (I stated within a week
or two after 3.3 is released, which is RSN).
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.
In most cases, there is no need. One just has to remember to put the
right thing in the CVS commit message, and it'll get added to the PR as
a comment.
Even saying "May fix Bug <x>" should make it do this. Then you'll see
the notice on gcc-bugs of the added comment, and there's your reminder.
You can easily query for bugs that haven't (or have) been touched in x
days in Bugzilla, so there is no need to put timestamps on bugs and
whatnot.
Given that i'd just have to remove the advice in bugs/management.html
in a few weeks when we move, why should we add it in the first place?
--Dan