Chris Hostetter wrote:
How/when should a resolved bug be closed?
I close bugs after their "fix version" is released.
The distinction between "resolved" and "closed" is intended for projects
with a formal QA process. An engineer fixes a bug and marks it
"resolved", and then a tester verifies the test and either closes it or
re-opens it if it has not been fixed. In our case, we're all testers.
Released, closed issues should generally not be re-opened. If there are
further problems related to an issue after a release is made and the
issue has been closed, then a new issue should be created. Why? If a
project has a Jira issues for every commit, and includes the issue name
in the commit message, then Jira's change log fully can fully document
the release, including links to subversion diffs, etc. But re-opening a
closed bug messes this up. It's better to add a new bug that links to
the old, closed bug.
We're trying to operate this way on Hadoop. Issues are entered for most
planned changes and assigned a "fix release". Then Jira's "road map"
feature can be used to see what features are planned for various
upcoming releases. This isn't perfect, since issues dropped for one
release are pushed to the next, and the list of issues per release
becomes unrealistically large (at least for the monthly release schedule
we're on). But on Hadoop we currently have dedicated resources who can
be assigned bugs and will work hard to fix them by a release date. I'm
not sure whether this would work on Lucene, which currently lacks such
dedicated resources, but it might be interesting to try.
(In my experience policy has tended towards the person fixing the bug to
"resolve" it, and the person who opened the bug to "close" once they're
verified the fix -- but that's not really possible with the way the Lucene
Jira project is setup, since anyone can open a bug, but only developers
can close them)
Note that I think it's okay to add folks the the "lucene-developers"
Jira group who are not Lucene committers. Some folks are very involved
with Lucene, but don't submit so many patches that they need to be a
committer. For such people it can make sense to have them able to help
manage Jira issues.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]