This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]