Date: Sun, 27 Dec 1998 12:10:18 +0100 (CET) From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD bugs <FreeBSD-bugs@FreeBSD.ORG> Subject: RE: PR states: what's the story? Message-ID: <XFMail.981227121018.asmodai@wxs.nl> In-Reply-To: <19981227154138.T12346@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <http://home.wxs.nl/~asmodai>; BSD & picoBSD: The Power to Serve <http://www.freebsd.org>; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.981227121018.asmodai>