From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10856 invoked by alias); 12 May 2003 00:58:21 -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 10768 invoked from network); 12 May 2003 00:58:21 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 12 May 2003 00:58:21 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b6) with ESMTP-TLS id 3950931; Sun, 11 May 2003 20:58:20 -0400 Date: Mon, 12 May 2003 00:58: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: 'Volker Reichelt ' , "'gcc@gcc.gnu.org '" , "'bangerth@ices.utexas.edu '" , "'giovannibajo@libero.it '" To: "S. Bosscher" From: Daniel Berlin In-Reply-To: <4195D82C2DB1D211B9910008C7C9B06F01F37334@lr0nt3.lr.tudelft.nl> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01067.txt.bz2 > >>> 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. > > We should have a "confirmed" state, which would mean that somebody > with GCC > PR DB write access can reproduce the bug (possibly after receiving > feedback). This is "NEW". There is an UNCONFIRMED state for UNCONFIRMED bugs. > "analyzed" should mean that at least the category is set and > that a reduced test case is available. > Why? you can mark them with a keyword or bug status flags. Stop overloading bug states for this functionality. Geez. >> Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED" >> if assigned to someone, "NEW" otherwise). > > Aieee, please no. There are so many analyzed PRs that are > unassigned, so what you say here would only make things harder. > > We should have "NEW" for new and unconfirmed PRs and "CONFIRMED" > for confirmed PRs. PRs should have the "ANALYZED" status when > somebody has zoomed in at the problem a bit closed. PRs that are > "analyzed" now should stay "ANALYZED" in bugzilla IMHO. > These should be bug flags, *not* states. > I don't know how many states you defined, gcc.gnu.org/bugzilla > used to work but now it fails... Chris upgraded perl today, apparently. Needs to reinstall some packages. > (Does Bugzilla allow you to > define your own states at all???) Yes, but there is no need in this case. > > >> 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. > > It's not unusual for a PR to be fixed without anyone noticing. > For 3.3, I closed some PRs that got fixed by some patch, but > the CVS commit message didn't mention the PR (probably because > nobody knew about the PR...) so the PR stayed open. I think > everybody has seen PRs like that. > >> 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. > > You can do that with GNATS, too. Just not very user friendly, > it _can_ be done. > > Greetz > Steven >