I suggest the following usage of the Jira issue resolved and closed. - An issue is marked as resolved if the developer would like to have somebody look at, depending on the level of confidence the developer has in the proposed solution, the urgency of the issue and the number of projected and files affected[1] the proposed resolution is in trunk or in an issue branch. The issue will stay with this status till somebody reviewed the proposed solution and either closes or reopens the issue. To prevent that many do the same review at this stage, the reviewer adds the comment "Review" when they start. Any committer may request a proposed solution to be removed from trunk, this has the same effect as a veto on a closed issue.
- An issue is marked closed either by the developer or the reviewer when the proposed solution has been committed to trunk and no second opinion is explicitly wished. With the closure of an issue a lazy consensus vote for 72h is opened on the proposed solution. If a veto is cast the issue is reopened and the person committing the solution must undo the change immediately [2] (but everybody else is free to do so), if more recent patches require the vetoed issue, the conflicting patches are removed and the respective issues reopened as well. Reto See also: http://www.apache.org/foundation/voting.html 1. If an issue affects many projects and file it gets harder to merge it back, so the cost of the branch is higher. If an issue branch is wished for an issue affecting many projects (I'd say, more than 4) it might be better clone the whole parent into the issue branch rather than the individual projects. 2.It need not disappear from the history, but the truk version must be changed back as if the change had never happened, an article on how to "rollback": http://jacwright.com/blog/75/how-to-roll-back-changes-using-subversion/
