From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18773 invoked from network); 5 Apr 2000 08:04:17 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Apr 2000 08:04:17 -0000 Received: (qmail 12292 invoked by alias); 5 Apr 2000 08:04:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10494 Received: (qmail 12284 invoked from network); 5 Apr 2000 08:03:59 -0000 Date: Wed, 5 Apr 2000 10:03:52 +0200 (MET DST) Message-Id: <200004050803.KAA01581@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 4 Apr 2000 15:39:17 +0000 Subject: Re: Closing bugs (?) Bart Schaefer wrote: > On Apr 4, 4:33pm, Sven Wischnowsky wrote: > } Subject: Closing bugs (?) > } > } Sourceforge supports the `fixed' and `closed' states. Hm, do we want > } to leave it to one of the administrators to actually close a bug or > } should the person who fixed (or tried to fix) it do that? > } > } And why this distinction? > > A bug can be closed without being fixed, i.e. "that's not a bug, it's a > feature," or "seeming bug was caused by pilot error," etc. > > The way I've typically handled it with GNATS before is that the person > who fixes the bug changes the state to "fixed" ("feedback" in GNATS), > and then it's up to the administrator and/or the person who reported > the bug to agree that it's fixed and change it to "closed". > > But maybe we don't need that much supervision, and maybe it's OK to > leave a bug in the "fixed" state forever. Hm. In this ugly Web-Interface we have (in the list), the state isn't shown, so you can only tell if a bug is (supposed to be) fixed after clicking on it etc. I think it would be nice to keep the list of open bugs small -- but of course that's only really a problem when there are more than there are now. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de