Subject: re: PRs should first have submitted status rather than open
To: Petri Koistinen <>
From: Greg A. Woods <>
List: netbsd-bugs
Date: 05/25/2001 03:38:01
[ On Friday, May 25, 2001 at 09:56:28 (+0300), Petri Koistinen wrote: ]
> Subject: re: PRs should first have submitted status rather than open 
> In GNATS open status is representing submitted, assigned and turnedin.
> analyzed is fixed, feedback is evaluated, GNATS closed is closed and
> rejected. And finaly suspended is ClearQuest postponed. So you can see
> that GNATS is matching with ClearQuest in end of PR life-cycle quite well,
> but in start of life-cycle, GNATS open status has given too much of
> "responsibility".

I think you are missing the point about the "responsible" field.

Once a developer has changed the "responsible" field then the PR is, by
definition in NetBSD at least, 'assigned' (since apparently the default
"responsible" party represents an unassigned status in the NetBSD PR
repository).  There's no need for a new "state" field value -- the new
state you wish to identify is inherently defined by the delta of the
responsible field in combination with the current 'open' state.  From

States of Problem Reports

   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.

     The initial state of a Problem Report.  This means the PR has been
     filed and the responsible person(s) notified.

     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.

     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.

     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.

     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.

> And about that familary with GNATS, you can't make any improvement without
> changing anything or in other words "you can't make omelet without
> breaking the eggs." And realy, everyone who is smart enough to use GNATS
> is capable of understand why this kind change is made.

I agree that NetBSD PR summary reports would be more informative if they
identified 'assigned' PRs.  However all that's necessary is to add a new
"report" to queue-pr (or even a wrapper for it) that can detect the
change in the responsible field.

This is easily visible in the full PR because the change is documented
with new ">Audit-Trail:" lines of the form:

     Responsible-Changed-From-To: FROM-TO
     Responsible-Changed-When: DATE

I think that it should be relatively easy to ensure that the originator
of the PR also gets a notification of the "responsible" change, though
maybe not without changing internals code (I don't remember what the
default rules are).

It would probably also help if the full GNATS manual were available in
more places, such as at least on

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>     <>
Planix, Inc. <>;   Secrets of the Weird <>