From owner-freebsd-bugbusters Thu Apr 25 11:11:48 2002 Delivered-To: freebsd-bugbusters@freebsd.org Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by hub.freebsd.org (Postfix) with ESMTP id 0A88537B405 for ; Thu, 25 Apr 2002 11:11:38 -0700 (PDT) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g3PIBWg16893; Thu, 25 Apr 2002 19:11:36 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: (from mark@localhost) by dotar.thuvia.org (8.11.6/8.11.6) id g3PIBWB79417; Thu, 25 Apr 2002 19:11:32 +0100 (BST) (envelope-from mark) Date: Thu, 25 Apr 2002 19:11:32 +0100 (BST) From: Mark Valentine Message-Id: <200204251811.g3PIBWB79417@dotar.thuvia.org> In-Reply-To: Dag-Erling Smorgrav's message of Mar 19, 12:30am X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: des@ofug.org (Dag-Erling Smorgrav), bugbusters@freebsd.org Subject: Re: PR state revision Sender: owner-freebsd-bugbusters@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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 "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugbusters" in the body of the message From owner-freebsd-bugbusters Thu Apr 25 23:15:54 2002 Delivered-To: freebsd-bugbusters@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id D239F37B405 for ; Thu, 25 Apr 2002 23:15:49 -0700 (PDT) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020426061549.CHOO25242.rwcrmhc53.attbi.com@blossom.cjclark.org>; Fri, 26 Apr 2002 06:15:49 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g3Q6Flq34653; Thu, 25 Apr 2002 23:15:47 -0700 (PDT) (envelope-from cjc) Date: Thu, 25 Apr 2002 23:15:47 -0700 From: "Crist J. Clark" To: Mark Valentine Cc: Dag-Erling Smorgrav , bugbusters@FreeBSD.ORG Subject: Re: PR state revision Message-ID: <20020425231547.A34367@blossom.cjclark.org> References: <200204251811.g3PIBWB79417@dotar.thuvia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204251811.g3PIBWB79417@dotar.thuvia.org>; from mark@thuvia.demon.co.uk on Thu, Apr 25, 2002 at 07:11:32PM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-bugbusters@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Apr 25, 2002 at 07:11:32PM +0100, Mark Valentine wrote: [snip] > 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. Too late. It's a done deal and a change that most everyone felt was too long coming. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugbusters" in the body of the message From owner-freebsd-bugbusters Fri Apr 26 15:47:18 2002 Delivered-To: freebsd-bugbusters@freebsd.org Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by hub.freebsd.org (Postfix) with ESMTP id 4221837B41E; Fri, 26 Apr 2002 15:47:12 -0700 (PDT) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g3QMlAg23439; Fri, 26 Apr 2002 23:47:10 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: (from mark@localhost) by dotar.thuvia.org (8.11.6/8.11.6) id g3QMl9Y24886; Fri, 26 Apr 2002 23:47:09 +0100 (BST) (envelope-from mark) Date: Fri, 26 Apr 2002 23:47:09 +0100 (BST) From: Mark Valentine Message-Id: <200204262247.g3QMl9Y24886@dotar.thuvia.org> In-Reply-To: "Crist J. Clark"'s message of Apr 25, 11:15pm X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Crist J. Clark" Subject: Re: PR state revision Cc: Dag-Erling Smorgrav , bugbusters@FreeBSD.ORG Sender: owner-freebsd-bugbusters@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: "Crist J. Clark" > Date: Thu 25 Apr, 2002 > Subject: Re: PR state revision > On Thu, Apr 25, 2002 at 07:11:32PM +0100, Mark Valentine wrote: > [snip] > > > 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. > > Too late. It's a done deal and a change that most everyone felt was > too long coming. Well, I'll deal with it if it's done. I'd still like to catch up on the reasoning and other previous discussions, though. Any and all feedback on what I had to say is welcome - I'd like to figure out if I can actually do something useful here. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugbusters" in the body of the message