Date: Thu, 25 Apr 2002 19:11:32 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: des@ofug.org (Dag-Erling Smorgrav), bugbusters@freebsd.org Subject: Re: PR state revision Message-ID: <200204251811.g3PIBWB79417@dotar.thuvia.org> In-Reply-To: Dag-Erling Smorgrav's message of Mar 19, 12:30am
next in thread | raw e-mail | index | archive | help
> From: des@ofug.org (Dag-Erling Smorgrav)
> Date: Tue 19 Mar, 2002
> Subject: PR state revision
[I'm just catching up after finding this message in -bugs via a search.
Is the -bugbusters archive supposed to be working? I've just signed up
and nothing seems to be archived for it.]
I'm interested in seeing what can be done to improve the processing of
FreeBSD PRs, especially in getting old PRs closed and in making it easier
to see the wood for the trees in general.
Can anyone give me a pointer to discussions on this subject so far?
> In light of the controversy and confusion that reign over the precise
> meaning of the "feedback" state, I would like to suggest the following
> revision of the Gnats states:
>
> open Default state for a new problem report.
>
> analyzed The problem is understood and a solution is being sought.
>
> suspended Work on this PR has been suspended due to lack of
> information or resources.
>
> feedback Further work requires additional information from the
> originator or the community - possibly confirmation of
> the effectiveness of a proposed solution.
>
> patched Patch has been committed, but some issues (MFC and / or
> confirmation from originator) are still open.
>
> closed PR has been resolved or abandoned.
>
> The most significant change is the addition of the "patched" state,
> and the ensuing disambiguation of the "feedback" state.
I'm fine with all that except for "patched". I'm reluctant to add new
GNATS states without _very_ good reason, since it plays havoc with
existing tools and familiar processes.
I'd rather work within the existing GNATS structure (ideas such as
adding the [PATCH] prefix in the synopsis seem to work reasonably well).
Specifically, "confirmation from originator" == "feedback", and the
remaining example is very specific and partly addressed with the
automated MFC reminder system.
For the pending MFC case, I can see a few options:
(a) just note in the audit trail that the PR can be closed once the
MFC has occurred (like the existing suggestion for unconditional
"This PR can be closed" tagging);
(b) tag the synopsis with [MFC];
(c) just close the PR and assume the MFC reminder is good enough
(don't close if the MFC reminder wasn't triggered, though).
> I would also
> like to encourage the use of the "analyzed" state where appropriate.
STRONGLY agreed!
In fact I tend to treat "analyzed" as an important marker which simply
indicates that the PR has been looked at and sanity checked. (The re-
assigning from -bugs to an individual isn't strong enough, that just
means that a committer thinks he knows who is more likely to make sense
of the PR.) It doesn't even have to be fully understood if the assignee
is yet to complete a dialogue with the submitter to illicit further
information.
This means that a time limit can be set on how long a PR _should_ remain
"open" (the timeout triggers a "Have we dropped the ball on this one?"
event, where you need to look and see if the assignee is still there,
or the PR has in fact been inappropriately assigned).
For example, here's the partial output of the summary script I use, which
I've modified for FreeBSD use.
Pri S PR Category Who Synopsis
--- - ----- -------- -------- -------------------------------------------------
*** ! 4782 kern dillon Under certain conditions, several krsh's in a row
*** ? 6630 kern phk [PATCH] Fix for Cyrix I8254 bug
*** ! 7057 i386 mdodd 3Com 3C509 locks up, or has >1000ms rtt under 100
*** ! 7264 kern gibbs Buslogic BT 950 scsi card not detected
*** ! 8099 gnu obrien [patch] some bugs in cpio
*** ! 8861 kern mdodd under heavy (multi interface) traffic ep0 freezes
*** ? 10172 kern [panics] Kernel (esp kern/sys_pipe.c) dies on low
*** ! 11525 misc dwmalone [PATCH] Networking patches to increase # interfac
*** ? 12395 kern gibbs Buslogic SCSI cards (BT948) time out under light
*** ! 12623 alpha -alpha Certain valid numeric strings cause a SIGFPE when
*** ! 13059 i386 imp Install aborts with panic:aha0: Invalid CCB Opcod
*** ! 13740 kern jlemon wrong IP statistics
*** ! 14697 bin grog Exploitable buffer overflow in Vinum (FreeBSD 3.3
*** ! 14946 i386 mjacob rmt - remote magtape protocol
*** ! 15825 kern dillon Softupdates gets behind, runs the system out of K
*** ! 16708 kern wpaul 3Com 3c900-Combo Ehternet card make kernel panic.
*** ! 16802 i386 An user math program have the system on K6-2/III
*** ! 17391 i386 jhb FreeBSD boot loader does not recognize keyboard o
These are all high priority PRs (see my comment about priority vs. severity
below), the '!' state is "open" ("needing attention!"), "?" is feedback.
Ideally, most PRs would be "open" (which I mark with a space in this field).
A blank "Who" is an unassigned PR (really freebsd-bugs).
Here's an example for a single assignee.
Pri S PR Category Who Synopsis
--- - ----- -------- -------- -------------------------------------------------
*** ! 32619 bin des libfetch does not use RFC 1738's definiton of ftp
** ! 5587 kern des session id gets dropped
** ! 27522 kern des linprocfs:/proc/stat does not handle SMP hosts
** ! 27543 kern des /proc/cpuinfo does not handle SMP hosts
** 28171 bin des [PATCH] to support a HTTP_REFERER env variable in
* ! 19913 kern des add SYN+FIN counter
* ! 20613 bin des fetch -T n is not timeout correctly when target s
* ! 33299 i386 des -CURRENT ptrace(2) implementation for linux emula
* ! 33300 i386 des -STABLE ptrace(2) implementation for i386 linux e
* ! 33856 bin des "fetch -o" gives bogus error message
* ! 34629 bin des fetch(1) cannot download RH 7.2 ISOs from www.lin
* ! 37079 bin des fetch complains about "size of remote file is not
(Hmm, apart from the "!"s, not at all bad for a project of this size! ;-)
By the way, I run these scripts using my local copy of the PR database.
I have a "standard" GNATS installation (not the port) which manages
multiple databases (and isn't release-based) [I have a small patch
to /usr/bin/send-pr to call the "real" one in the non-FreeBSD case].
I could document how this is done if it would help bugbusters query
the PR database more efficiently.
I prefer to sort on "priority" (the importance to the project of having the
PR worked on), than "severity" (the impact to the submitter), since these
aren't always equal. Older PRs come first after priority as a nagging
measure.
Is there currently any automated reporting of an assignee's open PRs,
or is it left to individuals? (I know about the overall project summaries
on -bugs, but I send myself one like the second example above on a weekly
basis for each of my projects.)
> Adding the "patched" state will require modifying the web search form
> and script, and doing a sweep to move "feedback" PRs to "patched"
> where appropriate.
...and modifying ad hoc tools which know about the standard GNATS
states (such as my summary scripts, tkgnats, and so on).
> I will also create and publish a state diagram documenting the
> different states and the recommended transitions from one to the
> other.
That would be quite useful. I'd also like to work on refining the
procedural documentation to help out those working on PRs.
This would cover stuff such as "Where to start?" (e.g. new unanalyzed
PRs in areas you're familiar with, old high-priority unanalyzed PRs,
chase up feedback timeouts, etc.), "How to progress a PR", re-prioritising
old PRs (an ancient high priority PR clearly wasn't! [though it may
still be high impact]), and so on.
Anyway, those are a selection of my current thoughts. I'd like to get up
to speed on the current views of the community, and see what can be done to
help the situation given the constraints of the volunteer system.
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>;
"Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses
"We're kind of stupid that way." *munch* *munch* and endorses FreeBSD
-- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugbusters" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204251811.g3PIBWB79417>