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]

Reply via email to