From owner-freebsd-bugs Sun Dec 27 03:04:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA03503 for freebsd-bugs-outgoing; Sun, 27 Dec 1998 03:04:08 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA03457 for ; Sun, 27 Dec 1998 03:04:04 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from chronias.ninth-circle.org ([195.121.56.13]) by smtp05.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA638B; Sun, 27 Dec 1998 12:03:40 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19981227154138.T12346@freebie.lemis.com> Date: Sun, 27 Dec 1998 12:10:18 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Greg Lehey Subject: RE: PR states: what's the story? Cc: FreeBSD bugs Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 27-Dec-98 Greg Lehey wrote: > I suspect that, as a result, many people haven't read this > documentation. You should; it makes things a lot clearer. It also > suggests that we're not doing things according to the book. Since > it's written by Cygnus, I can see a lot of NIH reasons for not doing > so, but in fact what I see seems eminently reasonable. Here's one: Funny enough, I spend the last two weeks scourging the net to everything that has to do with coding, including things like GNATS, JitterBug, and a bunch of others. And I also noticed that we adopted a different style with regard to the states, as you pointed out here Greg. > Each PR goes through a defined series of states between origination > and closure. The originator of a PR receives notification > automatically of any state changes. > > Unless your site has customized states (see see Section 3.2.6 > [states file], page 42), gnats uses these states: > > > open The initial state of a Problem Report. This means the PR has > been filed and the responsible person(s) notified. Is the same under development. > analyzed The responsible person has analyzed the problem. The > analysis should contain a preliminary evaluation of the > problem and an estimate of the amount of time and > resources necessary to solve the problem. It should also > suggest possible workarounds. Oi, we have a slight problem here, most of the bugs have no responsible person. Sure, some areas have people that we automatically burden with PR's because they have been doing a lot of work on. > feedback The problem has been solved, and the originator has been > given a patch or other fix. The PR remains in this state > until the originator acknowledges that the solution > works. We (ab)use this state actually for the fact that we need more details from the originator. Feedback is really the best term for that. However for the above I would suggest a customized state named: verification or test or something along those same lines as it would denote that fixes are available but need to be tested or verified by the originator. [ snip closed ] > suspended Work on the problem has been postponed. This happens if > a timely solution is not possible or is not > cost-effective at the present time. The PR continues to > exist, though a solution is not being actively sought. > If the problem cannot be solved at all, it should be > closed rather than suspended. > > Note that no PR gets closed without the consent of the submitter. I > think this is reasonable: a PR describes the user perception of the > matter. That doesn't mean they stay open for ever, of course: they > either go into `feedback' (if people don't answer mail messages) or > `suspended' (if nobody wants to fix it). > > Still, this is a little inadequate: there's no state to show the most > common state, where the assignee is trying to get more information > from the submitter. I think this should be `feedback' as well. It will be a little chaotic if the PR's have one-liners... Good documentation of PR's then becomes a real must. > But we have an escape clause: ``Unless your site has customized > states, gnats uses these states.''. Do we have customized states? If > so, I suppose we should look at the definitions. AFAIK, we have no customized states. I do think we might need one of two just to differentiate between real feedback regarding more details and feedback in a way of: "try this fix please". The former keeping the same name, the latter renamed to something like test or verify... --- Jeroen Ruigrok van der Werven Life is the only Pain asmodai(at)wxs.nl we endeavour... Network/Security Specialist BSD & picoBSD: The Power to Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message