[ 
https://jira.duraspace.org/browse/DS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20380#action_20380
 ] 

Tim Donohue commented on DS-906:
--------------------------------

Mark,

I'd highly recommend *against* reopening any issue which has already seen a 
formal release in DSpace.  Doing so can "play havoc" with our current 
(auto-generated) History page at: 
https://wiki.duraspace.org/display/DSDOC/History    Essentially, that History 
page tracks which *version* each patch/fix was released in.  So, for example, 
if you were to reopen DS-525 (which is listed as being released in 1.7.0), 
change it, and then change its "fixed" version to 1.8.0, suddenly it'd no 
longer be tracked as being originally released in 1.7.0.  Even if you listed it 
as *both* released in 1.7.0 and 1.8.0, we'd no longer have any human-readable 
information regarding *exactly what new changes* went into 1.8.0.   
Essentially, it's a "can of worms", and the best way to avoid it is to instead 
open up a *new bug report* and link it to the older, closed issue.  That way, 
new issues/fixes can be tracked & released *separate* from older, already 
released code.

Hopefully this makes sense -- essentially, we should *only* reopen issues if 
they are both "not fixed properly" AND unreleased.  As soon as they become 
"released", they appear in our History page.  So, to avoid oddities/inaccurate 
tracking in our History page, after that point, we should recommend opening a 
new issue to describe new concerns/problems and linking it back to the older, 
closed issue.

As for DS-171, I'm actually not sure why you reopened that issue?  It was 
previously marked as "closed" & "won't fix" because it specifically described a 
"hack/customization" which could be used to implement Embargo in pre-1.6.0 
DSpace JSPUI (that hack/customization is described here: 
https://wiki.duraspace.org/display/DSPACE/Embargo+on+Bitstream+%28JSP%29).   As 
soon as 1.6.0 came out, it released an entirely different Embargo framework, 
which essentially made the implementation described in DS-171 obsolete.  So, 
I'm not sure you actually should have reopened DS-171, as it describes an 
obsolete implementation of Embargo.  Rather, if there are existing embargo 
concerns/issues, they likely should instead be logged as new issues.

OK -- I realize we've now "gone off the deep end" in terms of these comments.  
None of these recent comments (mine included) have much to do with DS-906 
itself -- so, we both may want to move this ongoing discussion to dspace-devel 
:)

> For moving items in the Admin UI, add checkbox option to replace resource 
> policies with defaults of the new collection
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: DS-906
>                 URL: https://jira.duraspace.org/browse/DS-906
>             Project: DSpace
>          Issue Type: Improvement
>          Components: XMLUI
>    Affects Versions: 1.7.2, 1.8.0
>            Reporter: Bill Hays
>
> This is a single call in the API: 
> item.inheritCollectionDefaultPolicies(targetCollection)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to