I think we should just impose a limitation on the period that a bug
remains in RESOLVED state after the release in which it is marked as
such. Something like 60 days is probably more than adequate given our
release cycles and the amount of change; maybe 30 days would work..
After that point there's usually not a lot of difference between an
end-user re-opening versus opening a new bug and referring back if
necessary. Most end users will leave it to us to recognize it as a
regression or duplicate (unless they happen to have been a watcher or
filer on the original bug and remember it). We would then just
uniformly go in and close bugs that are in RESOLVED states for more than
30 (or 60) days, provided we have the timestamps.
The harder part is establishing more rigor ourselves around looking at
the bug list regularly and cleaning up old bugs that should really be
RESOLVED in one of the non-fixed states because they are bogus, not
reproducible, or simply not really applicable to the current code base
anymore. I notice Linda has been doing some of this cleanup, and it's
very much needed work.
--a.
Matt Raible wrote:
On 3/2/06, David M Johnson <[EMAIL PROTECTED]> wrote:
Linda Skrocki, our program manager at Sun has been helping out by
reviewing the bugs in JIRA, looking for duplicates and work that's
already been completed. She is in the process of CLOSING a lot of
bugs that I marked RESOLVED. I have always used RESOLVED to indicate
that a bug is fixed and I'm done working on it. So think of this as a
"cleanup the database before it's transfered to Apache" measure.
It might be time to have a discussion about how those bug states
figure into our release process, so we know what to do moving
forward. Here are the workflow steps in JIRA and how they might be
interpreted:
Open - when an issue has arrived
In progress - when a developer started working on an issue
Resolved - when a developer claims a bug is fixed
Reopened - when a resolved issue turns out not to have been resolved
Closed - when a tester or end-user verifies that bug is fixed
"Closed" is a tricky one. Who can close a bug? Must that be a
committer? What if none of our testers are committers? Must a
committer verify each bug before it is closed?
I believe how JIRA works is that we'll have to close the bug (b/c end
users won't have rights). I have noticed that issues can't be
re-opened by end users after they've been closed - that's why
"resolved" is nice.
What does JIRA's documentation say?
Matt
- Dave
