From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17456 invoked by alias); 23 May 2003 16:14:18 -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 17444 invoked from network); 23 May 2003 16:14:17 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 23 May 2003 16:14:17 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b6) with ESMTP-TLS id 4058087; Fri, 23 May 2003 12:14:17 -0400 Date: Fri, 23 May 2003 16:18:00 -0000 Subject: Re: your RESOLVED->CLOSED changes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: bangerth@ices.utexas.edu, giovannibajo@libero.it, pfeifer@dbai.tuwien.ac.at, neroden@twcny.rr.com, ehrhardt@mathematik.uni-ulm.de, ebotcazou@gcc.gnu.org, gcc@gcc.gnu.org To: Volker Reichelt From: Daniel Berlin In-Reply-To: <200305231437.h4NEbwNZ006140@relay.rwth-aachen.de> Message-Id: <98AB1BCE-8D39-11D7-B31E-000A95A34564@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg02106.txt.bz2 On Friday, May 23, 2003, at 10:37 AM, Volker Reichelt wrote: > On 23 May, Wolfgang Bangerth wrote: >> >>> Right now, in order to change to CLOSED, you need to edit the bug >>> two times, >>> and this is suboptimal. >> >> I wasn't even aware of this. Which might or might not indicate that >> the >> process is too complicated. >> >> Regarding the existence of the two states at all: I have argued >> previously >> that that's unnecessary. Nathanael says that we need them for the >> otherwise lack of QA in gcc, but I think that's not correct: every >> patch >> for a bug should come with a testcase, so at least in theory a bug >> that >> has once been fixed cannot reappear because it would show up in the >> testsuite. >> >> I get the feeling that this requirement is quite thoroughly handled. >> If it >> is not in some cases, then I think it is an undue burden on the >> bugzilla >> people if they have to maintain two states for _all_ bug reports. >> It's an >> undue burden because it can't be their responsibility to enforce the >> testcase rule, but they would be forced to bear the consequences. >> >> I would also like to posit that quite a number of bugs will then stay >> RESOLVED indefinitely. If someone, say, fixes a bug on mn10200 or some >> other obscure target, who's going to double-check after a release and >> put >> in into CLOSED? > > Full Ack! > > We've got more than 1600 open PRs. And we introduce a lot of bugs > with each new major release (although this seems to get better). > So I don't mind the couple of bugs slipping through the cracks of > the testsuite. They will be found like all the other bugs were > found. Having two states or more for closed bugs just wastes > resources that we need for managing the bug database and > confused the users IMHO. Okay guys, let me see if i can clear a few things up: 1. There is no need to mark bugs closed, actually, unless you want to do QA. This can be viewed as mistake on my part during conversion, mapping GNATS's closed to CLOSED rather than RESOLVED. 2. Bugs with states CLOSED, RESOLVED, and VERIFIED are considered closed bugs. This is actually coded into Bugzilla (The reason i haven't removed VERIFIED and CLOSED is because it would make for a bunch of merge conflicts whenever i import new bugzilla sources). sub OpenStates { return ('NEW', 'REOPENED', 'SUSPENDED', 'WAITING', 'ASSIGNED', $::unconfirmedstate); } $vars->{'closedstates'} = ['CLOSED', 'VERIFIED', 'RESOLVED']; I can make VERIFIED and CLOSED options invisible to the user, so that you don't ever see it, if you like. Making RESOLVED invisible, or changing it's name, is harder, though possible. You can leave things resolved, rather than closed, and the world will not end. > > Regards, > Volker > >