Team,
As those of you who have been contacted by me are aware, I've been cleaning
up OPNFV JIRA. One of the things I've been working on is transitioning
issues with status = "Resolved" to status = "Closed". Especially for
issues that are either assigned to old releases, or issues that are not
assigned to any release ("fix version" = empty).
So, what's the point? Why do this?
First, you need to understand the difference between "Resolved" and
"Closed". Marking an issue as Resolved is an assertion that the issue no
longer needs to be fixed. This could be for a wide variety of reasons
(fixed, cannot reproduce, duplicate, etc.). However, what if that
assertion is incorrect? Perhaps the developer didn't understand how to
reproduce the issue.
So, the additional transition from Resolved to Closed gives us an
opportunity to have an additional gate to verity the assertion of the
developer that resolved the issue. Of course, you can always reopen an
issue, but the status of "Resolved" is a flag the resolution still needs to
be verified, while the status of "Closed" indicates that the issue requires
no further action.
So, what are the best practices? Ideally, the person that resolves a bug
should be different from the person that reported the bug. I realize that
it's common practice, especially on small teams, to report and resolve your
own issues. This is good from the standpoint of documentation, but is
subject to confirmation bias. Perhaps, more importantly, the person that
marks the issue Closed should be different from the person that resolved
the issue. This could be the reporter, but would benefit from being yet
another person.
You can use gerrit to your advantage here. When you submit a patch, you
can mark the bug Resolved. If you get a -1 or -2, then you can re-open the
bug. Once you get +2 (preferably by another person), then you can mark the
bug Closed.
In any case, whatever process you decide on, it would be helpful if you
could make sure that your resolved issues for the current release cycle (or
past release cycles) get closed by the end of the current release cycle, at
the latest.
If you'd like to see what issues in your project are marked as Resolved and
that are assigned to an old release, or no release, see this link
<https://jira.opnfv.org/issues/?jql=status%20%3D%20Resolved%20AND%20fixVersion%20in%20(EMPTY%2C%203.0%2C%205.0.0%2C%205.1.0%2C%205.2.0%2C%20Arno%2C%20Brahmaputra%2C%20%22Brahmaputra%202.0%22%2C%20%22Brahmaputra%20SR1%22%2C%20%22Brahmaputra%20SR2%22%2C%20%22Colorado%201.0%22%2C%20%22Colorado%202.0%22%2C%20%22Colorado%203.0%22%2C%20%22Colorado%20and%20before%22%2C%20%22D%20and%20E%20release%22%2C%20%22Danube%201.0%22%2C%20%22Danube%202.0%22%2C%20%22Danube%203.0%22%2C%20%22Dovetail%20Danube%22%2C%20E%2C%20%22OPNFV%20Release%20C%22%2C%20%22Version%205.0.0%22%2C%20%22Version%205.0.1%22%2C%20%22Version%205.0.2%22)%20ORDER%20BY%20project%20ASC>
(sorted alphabetically by project). Please close them, if possible.
Let me know if you have any questions.
David
--
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: [email protected]
Skype: davidjmcbride1
IRC: dmcbride
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
