Date: Sun, 27 Dec 1998 15:41:38 +1030 From: Greg Lehey <grog@lemis.com> To: FreeBSD bugs <FreeBSD-bugs@FreeBSD.ORG> Subject: PR states: what's the story? Message-ID: <19981227154138.T12346@freebie.lemis.com>
next in thread | raw e-mail | index | archive | help
Now I have two PRs which I have to look at, so I'm trying to finally
figure out how to use GNATS. The first trick was to find and format
the documentation, which isn't done automatically (as of now, go to
/usr/ports/databases/gnats/work/gnats-3.106-beta/gnats and do 'make
gnats.dvi', then find a way to print it on your printer).
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:
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.
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.
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.
closed A Problem Report is closed ("the bug stops here") only when
any changes have been integrated, documented, and tested,
and the submitter has confirmed the solution.
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.
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.
Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key
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?19981227154138.T12346>