John Ellson wrote:
Dave Jones wrote:
- When bugs have been in NEEDINFO states for _months_. If the user has got tired reporting 'bug still there', there's not a lot more I can do, and closing these bugs does 'wake up' a bunch of dormant bugs.
A problem with the NEEDINFO states is that the bug disappears from the "my bugs" query in bugzilla, so if the user misses the email (or puts it off and then forgets) the bug is probably lost.
My suggestion is "make a better bugzilla query" then. I don't know what our other developers do, but personally, I don't use any of the bugzilla pre-baked buttons/knobs/whistles, as they are totally inadequate for my purposes. I don't use any bugzilla "stored queries" either.
In theory, stored queries is nice as you can log into bugzilla from any computer, and have all your normal queries there. That is probably beneficial to some people, but I work from home, and have a master workstation that all bugzilla'ing is done from so bookmarks give me the same functionality as stored queries, but with IMHO more flexibility.
I set up various highly custom queries to find bugs in any open bug state, which includes the various NEEDINFO states, etc. I've got queries for mharris owned bugs, for xgl-maint owned, for both, for bugs filed against specific components, specific OS releases, for bugs in specific states or groups of states, etc. This allowes me the most flexibility in spitting out a list of a subset of all bugs, which I'd like to focus on at any given point.
In addition to that, we have an internal tool named MCP which is a task-based frontend to bugzilla and various other internal Red Hat infrastructure. MCP is a huge help to our engineers in focusing in on a specific area of bugs, such as "FC5Blocker" or "RHEL4U8 updates" and whatnot. Mind you, this tool is not visible publically (nor would it really be useful to the general public if it was), although now that I've mentioned it, I'm sure somebody will whine about the fact we have private internal tools which they can't see/use. Oh well, deal with it. ;o)
There is an RFE for bugs in the NEEDINFO state to be listed in "my bugs" in BZ# 174930
I don't use the NEEDINFO state much anymore myself. I generally use NEEDINFO_REPORTER or NEEDINFO_ENG, etc. as that makes it more explicit as to who the bug is waiting on info from. My NEEDINFO bug queries are all updated to get all NEEDINFO* bugs at once. A bug being in one of the NEEDINFO* states however does not actually mean that info is in need of info though, as quite often the reporter adds the info which has been requested, and simply does not change the bug back to ASSIGNED (either they don't realize they need to do this, or they forget or whatever). At other times, a bug might already have enough info present, but an engineer or someone else might ask for some additional info to be added if possible, but which isn't strictly mandatory in order to proceed.
Due to the last 2 factors I cite, and perhaps some others I'm not thinking of now, there is no sane way that anyone should be concluding that since a bug is in NEEDINFO* state for n days, that the bug should be automatically closed, or have anything automatic done to it. The proper way of handling masses of bugs in NEEDINFO state, is to set up a few bug queries to bring them up in an organized fashion (or a subset of them), and then bringing up each bug individually and doing a manual skim/triage. I usually bring up my "show all NEEDINFO*" buglist, and then sort by last change date. I bring up 5 or so bugs at a time from the oldest last-changed date. Then I review them, and if the info was supplied and state not changed to ASSIGNED, I move it to ASSIGNED myself (or otherwise review the info, update the report and perhaps leave it in NEEDINFO* asking for more info, etc.) If myself or someone else has requested info about something and not ever received any form of response back at all, I might "ping" the report, or I might close it with a friendlyish stock response that asks the person to test the latest whatever out and reopen the bug if it is still present, etc.
There's a bit more to it all than this, but that is the general approach I take to masses of NEEDINFO bugs that are lying around for a long time. If there are too many to handle all in one sitting, I do a handful, and come back to them in a day/week/whenever I have the time.
Mass-closing all the bugs, or doing anything generic to all at once I think would in most cases just irritate the people who filed the bugs, perhaps enough so that they decide to never bother filing a bug again.
<humour> If one is planning on irritating people, it is much more fun to do it on an individual basis than doing it to everybody at once. </humour>
;o)