From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12726 invoked by alias); 11 May 2003 20:46:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12673 invoked from network); 11 May 2003 20:46:47 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 11 May 2003 20:46:47 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b6) with ESMTP-TLS id 3950666; Sun, 11 May 2003 16:46:47 -0400 Date: Sun, 11 May 2003 20:46:00 -0000 Subject: Re: Suggestion for a new GNATS policy Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: gcc@gcc.gnu.org, bangerth@ices.utexas.edu, giovannibajo@libero.it To: Volker Reichelt From: Daniel Berlin In-Reply-To: <200305112030.h4BKU4NZ015605@relay.rwth-aachen.de> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01059.txt.bz2 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 " 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