On 14 May 2010 13:43, Mark H. Wood <mw...@iupui.edu> wrote: > Closing could be part of the release process. When a fix is > incorporated into a release, the issue should be closed. To revisit it > after a release, a new issue should be linked to the old. But I > wouldn't want to do that without an intermediate "reviewed" state. >
I would still urge you to consider what the real implications of using the 'Closed' status are. Unlike 'in progress', or 'resolved' - which give a reasonably clear indication of what they mean, there really aren't any inferences that can be taken from 'Closed'. Other, that is, the actual implication of making something closed, which is that you can't alter the state of any field in the item without first re-opening the item. So, if you do want to reclassify something - maybe you change the configuration later to add new components or classifications that you want reflected in previously resolved issues - then you have to re-open it, and then resolve it again, remembering to set what the resolution was initially (ie. Fixed, Won't Fix, Duplicate, etc.) Yes, we can try and impose our own meanings on to Closed, but if we really want to mean something specific, then it is much, much better to create a new status that provides that meaning. If we want to say something is released, then we should create a 'released' status - but that's actually not very useful when you have an issue that might affect multiple versions, and we may choose to have multiple releases for the resolution - ie. if we found a serious enough issue in 1.5.2 now, we might choose to release 1.5.3 AND 1.6.2. Those releases would not occur at precisely the same time, so when would you transition the issue to 'released'? I have absolutely no problem with us using Closed if we want to take the administrative step of actually preventing an issue from being edited - but I stress that I believe we should only be doing because we want to take that administrative step, and not because we want to infer a meaning that 'Closed' doesn't convey. And note that we don't even have to take something to Closed just to prevent people (in general) from editing it. You can define different permission levels for different statuses. I think the important states to distinguish are: > > o we have an issue. > 'found', 'received', etc. > > o someone is working on it. Others should either avoid duplicate > effort or contact the assignee to offer help and receive > coordination. > 'in progress' > > o assignee thinks the work is done. > 'resolved' > o fix is independently tested and judged to work. > 'verified' > o fix is in a release. > I'm actually not convinced that we should have a status for this, for the reasons I gave above (multiple releases). Rather, you specify the fix version(s) in the issue, and the 'verified' status says that it will be in those releases - whether those releases have actually been released or not at that point, is known elsewhere. Additionally, it's important to have 'Open' - the issue is confirmed to exist and is awaiting someone to work on it 'Awaiting Response' - which means that it can't be progressed without additional information > It would be nice if the tool could also help us track *where* in SCM > space the fix is incorporated. That is, if it affects several > branches, have all known affected branches (and the trunk) been fixed? > It can track where it has been incorporated - providing the commit message contains the issue number. So, if you commit with the message: ' [DS-544 <http://jira.dspace.org/jira/browse/DS-544>] Removal of mapped items can lead to NPE ' you can go to the issue in Jira and see what commits / source is related to that issue: http://jira.dspace.org/jira/browse/DS-544?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel Or indeed, you can go to the FishEye panel: http://jira.dspace.org/jira/browse/DS-544?page=com.atlassian.jira.ext.fisheye%3Afisheye-issuepanel which then links through to the information about that checkin in FishEye: http://fisheye3.atlassian.com/changelog/dspace?cs=4941 G
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
