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)
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list