Timestamps are in GMT/BST.
[3:58] * cbeer (~cbeer@198.147.175.203) Quit (*.net *.split)
[3:58] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) Quit (*.net *.split)
[3:58] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (*.net *.split)
[3:58] * scottatm (~scottatm@voyager114.evans.tamu.edu) Quit (*.net *.split)
[3:58] * ablemann (~alexleman@147.226.128.170) Quit (*.net *.split)
[3:58] * ChanServ (ChanServ@services.) Quit (*.net *.split)
[3:58] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (*.net *.split)
[3:58] * snail (~yeatesst@130.195.179.88) Quit (*.net *.split)
[6:36] -card.freenode.net- *** Looking up your hostname...
[6:36] -card.freenode.net- *** Checking Ident
[6:36] -card.freenode.net- *** Found your hostname
[6:36] -card.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:51] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[7:51] * snail (~yeatesst@130.195.179.88) has joined #duraspace
[7:51] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[7:51] * ianthe (~ianthe@cowu.be) has joined #duraspace
[7:51] * cbeer (~cbeer@198.147.175.203) has joined #duraspace
[7:54] -tomaw- [Global Notice] Sorry for the outage there, it seems one of our hubs had some issue. We've re-routed around it for now.
[12:04] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[13:25] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (Read error: Connection reset by peer)
[13:28] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[13:36] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[13:53] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) Quit (Ping timeout: 240 seconds)
[13:54] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[15:13] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) Quit (Remote host closed the connection)
[15:13] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Remote host closed the connection)
[15:27] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) has joined #duraspace
[18:51] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[19:12] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[19:32] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:52] <tdonohue> Hi All, reminder we have our weekly DSpace Developers meeting here at the top of the hour: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[19:52] <kompewter> [ DevMtg 2011-09-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[19:59] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[19:59] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) has joined #duraspace
[20:00] * richardrodgers (~richardro@18.111.56.24) has joined #duraspace
[20:00] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[20:00] <tdonohue> Hi All. Time for our weekly DSpace Developers Meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[20:00] <kompewter> [ DevMtg 2011-09-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[20:01] <tdonohue> I don't have a specific agenda for today -- it's mostly a "catchup" on 1.8.0, and perhaps going through some of the issues that are still outstanding with 1.8.0 (or were just found during 1.8 Testathon)
[20:01] <tdonohue> the outstanding issues are all listed on our agenda page: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[20:01] <kompewter> [ DevMtg 2011-09-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[20:02] <richardrodgers> how do you want to tackle them?
[20:02] <tdonohue> robint, were there any specifically you wanted to talk about or get updates on today (I know you've been in touch with folks who have issues assigned to them)
[20:02] <robint> Could we have a brief discussion about the Tomcat 7 one ?
[20:03] <tdonohue> sure, DS-959
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-959 ] - [#DS-959] XMLUI login failure when using Tomcat 7.0.16 - DuraSpace JIRA
[20:03] <robint> There is an explanation now.
[20:04] <robint> I think, for the XMLUI you either have to make it the Root app in Tomcat
[20:04] <robint> or set some Tomcat config somewhere
[20:04] <robint> Its clear I haven't done my homework properly :)
[20:05] <tdonohue> yea, and I see mdiggory isn't here to update us
[20:05] <robint> Are we happy that this is good enough for us ?
[20:05] <richardrodgers> is the mentioned TC config documented for us?
[20:06] <robint> Not anywhere official
[20:06] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:06] <tdonohue> I personally wonder if there's anything else we *should* be doing to correct this issue. For instance, KevinVdV had a comment on there about how it works if you turn on "xml.user.loginredirect" config in dspace.cfg
[20:06] <robint> I think its described in the Jira issue
[20:06] <KevinVdV> Yeah it just seems to lose the session only on the home page
[20:06] <tdonohue> there's mdiggory. Mark, we are discussing what to do with DS-959 (Tomcat 7 issues) to "fix it"
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-959 ] - [#DS-959] XMLUI login failure when using Tomcat 7.0.16 - DuraSpace JIRA
[20:07] <mdiggory> my ears were burning...
[20:07] <tdonohue> :)
[20:08] <tdonohue> So, it sounds like, at a minimum we can *document* the 'sessionCookieUsesTrailingSlash' setting. But, I wondered if there was anything else we should be doing to fix this (i.e. are we actually doing something "wrong" with how we redirect users after authenticating)
[20:08] <KevinVdV> I noticed then when the xml.user.loginredirct is switched on the session will remain stored through ALL the pages
[20:08] <mdiggory> tell everyone to use Weblogic
[20:08] <KevinVdV> EXCEpt when going to the home page
[20:08] <mdiggory> err, Resin
[20:08] <mdiggory> err, Jetty
[20:08] <KevinVdV> When you move to the home page at any time the session is lost
[20:10] <mdiggory> KevinVdV: it sounds like the "wrapped" request is maybe loosing its session in this case?
[20:10] <tdonohue> KevinVdV -- so it sounds like, essentially as long as there *is* a slash after your Tomcat WebAppPath, then everything is fine. But, as soon as that slash isn't there (e.g. homepage without a trailing slash), then it doesn't work.
[20:11] <KevinVdV> I believe so (at least those are my findings)
[20:13] <mdiggory> //redirect the user to the normal login page
[20:13] <mdiggory> String loginRedirect = ConfigurationManager.
[20:13] <mdiggory> getProperty("xmlui.user.loginredirect");
[20:13] <mdiggory> redirectURL += (loginRedirect != null) ?
[20:13] <mdiggory> loginRedirect.trim() : "";
[20:13] <mhwood> Has anyone tried asking about this on the Tomcat Users list?
[20:13] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[20:13] <mdiggory> if we put "/" instead of "", would this fix it?
[20:14] <KevinVdV> Tried it already I'm afraid the issue isn't the redirect
[20:14] <mdiggory> AuthenticateUserAction.java
[20:14] <KevinVdV> As soon as you go to the home page withouth the trailing slash the session is lost
[20:14] <KevinVdV> Didn't test with other pages withouth the slash though :$
[20:14] <KevinVdV> Just didn't find the time
[20:14] <mdiggory> because the cookie has a trailing slash in its path
[20:15] <mdiggory> is the session really ended or can you still go back to it if you use trail slash?
[20:16] <KevinVdV> I will need to test that gimme some time need to boot my windows for that
[20:16] <KevinVdV> I will get back to you on that mdiggory
[20:16] <hpottinger> so, documentation-wise, we need to add a pointer to this section: https://wiki.duraspace.org/display/DSDOCDEV/Installation#Installation-ServletEngine%3A%28ApacheTomcat5.5or6%2CJetty%2CCauchoResinorequivalent%29.
[20:16] <kompewter> [ Installation - DSpace Unreleased Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOCDEV/Installation#Installation-ServletEngine%3A%28ApacheTomcat5.5or6%2CJetty%2CCauchoResinorequivalent%29.
[20:18] <mdiggory> Also note this entire issue goes away when you run xmlui as your ROOT webapplication, correct?
[20:18] <tdonohue> mhwood : I think this is actually a DSpace issue or possibly a Cocoon config issue, to be honest (but I could be wrong). Tomcat 7 now has this new 'sessionCookieUsesTrailingSlash' param that defaults to 'true', which doesn't play well with our XMLUI login process
[20:18] <tdonohue> correct, mdiggory, that's my understanding
[20:19] <tdonohue> There are two quick fixes: (1) run your XMLUI as the ROOT webapp, or (2) set 'sessionCookieUsesTrailingSlash=false' in your webapp
[20:19] <mdiggory> Ugh... this is Internet Exploder breaking the internet again....
[20:19] <mdiggory> Some browsers, such as IE, will send a session cookie for a context with a path of /foo with a request to /foobar. To prevent this, Tomcat will add a trailing slash to the path associated with the session cookie
[20:20] <mdiggory> so, in the above example, the cookie path becomes /foo/. However, with a cookie path of /foo/, IE will no longer send the cookie with a request to /foo. This should not be a problem unless there is a servlet mapped to /*. In this case this feature will need to be disabled. The default value for this attribute is true. To disable this feature, set the attribute to false.
[20:20] <tdonohue> So, we can "quick fix" this with better Documentation, but again, .I think we should definitely investigate if there's something we should tweak in DSpace or Cocoon to actually "fix" this (so, I'll be interested to hear what KevinVdV discovers or any other testers)
[20:21] <mdiggory> This should not be a problem unless there is a servlet mapped to /*. == 90% of webapps on the internet today
[20:21] <mhwood> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html documents sessionCookiePathUsesTrailingSlash
[20:21] <kompewter> [ Apache Tomcat 7 Configuration Reference (7.0.21) - The Context Container ] - http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
[20:22] <tdonohue> Ok, is there anything else to mention here? Should we move on to other open issues?
[20:22] <KevinVdV> I have some more findings but I will attach em to the JIRA task
[20:23] <hpottinger> would a documentation change be considered enough to close this issue?
[20:24] <KevinVdV> Don't know T.b.h. I would keep it open byt for now a documentation change might suffice
[20:24] <tdonohue> hpottinger: I think docs are "OK" (so yea, if needed we could close it), but I have a feeling we can actually fix this with code (if we dig in more). So, I'd be "fine" with Docs, if that's all we can get done by 1.8
[20:25] <hpottinger> I'll sign on to change the docs for this, but will not close the issue
[20:25] <tdonohue> sounds good
[20:25] <KevinVdV> Thanks
[20:25] <KevinVdV> I will do some further investigation when I find the time but may require some aid
[20:25] <tdonohue> Ok, I'm just going to quickly run through some of these open issues for 1.8. Just looking for brief updates or volunteers.
[20:25] <tdonohue> DS-135
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-135 ] - [#DS-135] Withdrawn items displayed as "restricted" rather than withdrawn - DuraSpace JIRA
[20:26] <tdonohue> This is a longstanding issue (lack of XMLUI tombstone). Anyone want to grab it?
[20:26] <mdiggory> There are too many of these tickets... This one is not properly linked with all others.
[20:27] <tdonohue> mdiggory -- this is only loosely related to the whole string of tickets about that "Optional Tombstone Message".
[20:27] <robint> If I have time I'll have a look
[20:27] <mdiggory> We have two approaches to clearing up the tombstone issue in XMLUI
[20:27] <mdiggory> This should not be a problem unless there is a servlet mapped to /*.
[20:27] <tdonohue> (i.e. it's loosely related to DS-1004, but it's not the same thing)
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-1004 ] - [#DS-1004] Add optional reason text to tombstone page (XMLUI) - DuraSpace JIRA
[20:27] <mdiggory> ops...
[20:27] <mdiggory> https://jira.duraspace.org/browse/DS-587
[20:27] <kompewter> [ [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-587
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-587 ] - [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA
[20:27] <tdonohue> mdiggory -- DS-135 is a bug. It's *NOT* the same as DS-587
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-135 ] - [#DS-135] Withdrawn items displayed as "restricted" rather than withdrawn - DuraSpace JIRA
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-587 ] - [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA
[20:28] <hpottinger> KevinVdV give me a shout if you want another set of eyes on a code change for 959
[20:28] <richardrodgers> one could remove reason from 1004 and just fix the bug
[20:28] <mdiggory> DS135 is restructed because there is not a tombstone page
[20:29] <tdonohue> Ok, moving on. robint has said he'll look at DS-135 (and yea, the patch attached to Ds-1004 may be useful, as long as we just fix the bug, and don't bother with the "optional text" feature)
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-135 ] - [#DS-135] Withdrawn items displayed as "restricted" rather than withdrawn - DuraSpace JIRA
[20:29] <mdiggory> richardrodgers: to be honest, we need to determine which is the best approach
[20:29] <tdonohue> Next up, DS-598. Assigned to richardrodgers. Any updates?
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-598 ] - [#DS-598] SWORD will only accept deposits on the URL configured in dspace.cfg - DuraSpace JIRA
[20:30] <richardrodgers> mdiggory: yep, but I think this is an attempt to segregate the issues...
[20:30] <tdonohue> mdiggory -- again, Ds-587, Ds-1004 and all those related issues are not even "on the table". They are all being delayed for post-1.8.0. The only one we are trying to fix is Ds-135 (the bug)
[20:31] <richardrodgers> DS-598 - I can commit it - it's an old patch from grahamtriggs I believe
[20:31] <kompewter> [ https://jira.duraspace.org/browse/DS-598 ] - [#DS-598] SWORD will only accept deposits on the URL configured in dspace.cfg - DuraSpace JIRA
[20:31] <tdonohue> cool, thanks richardrodgers
[20:31] <tdonohue> next up, DS-599, assigned to mdiggory. Any updates?
[20:31] <kompewter> [ https://jira.duraspace.org/browse/DS-599 ] - [#DS-599] SOLR statistics file download displays all files and not only those in the Bundle Original - DuraSpace JIRA
[20:32] <robint> Think this may have been passed to KevinVdV ?
[20:32] <mdiggory> I was just going to ask if he wanted it
[20:32] <mdiggory> given he wrote the patch
[20:32] <tdonohue> Oh, sorry. Just going by who is assigned to it currently. KevinVdV are you taking over Ds-599?
[20:33] <KevinVdV> I am always willing to
[20:33] <robint> Poor guy, we are ganging up on him :)
[20:33] <tdonohue> you don't *have* to :) Just looking for a volunteer for Ds-599 :)
[20:33] <robint> KevinVdV: If you have a fix ready and the time then go for it. Cheers
[20:34] <KevinVdV> No problem at all
[20:34] <KevinVdV> The patch is ready
[20:34] <KevinVdV> & hopefully I will have some time to write a conversion script
[20:34] <KevinVdV> If mdiggory doesn't mind me stealing the task from him ?
[20:36] <tdonohue> I think mdiggory was offering it up. So, I'll assume one of you two will investigate DS-599. If you need help, just ask!
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-599 ] - [#DS-599] SOLR statistics file download displays all files and not only those in the Bundle Original - DuraSpace JIRA
[20:36] <tdonohue> next up, DS-612, currently assigned to richardrodgers. Any updates?
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-612 ] - [#DS-612] Unfinished submissions see cc-rdf file instead of their uploaded PDF in the uploads step. - DuraSpace JIRA
[20:36] <mdiggory> KevinVdV: Its yours
[20:36] <KevinVdV> *steals the JIRA from mdiggory*
[20:36] <richardrodgers> Yea, I'm tempted to close this - situation will be different
[20:37] <robint> Did thi only apply to XMLUI or to JSPUI also ?
[20:37] <PeterDietz> Hi, I've been working on something similar to Ds-559, I've added bundleName to my solr-stats schema, and can now query on which bundle it came from
[20:38] <PeterDietz> <lst name="bundleName">
[20:38] <PeterDietz> <int name="ORIGINAL">209644</int>
[20:38] <PeterDietz> <int name="THUMBNAIL">122803</int>
[20:38] <PeterDietz> <int name="LOGO-COMMUNITY">1081</int>
[20:38] <PeterDietz> <int name="PROXY-LICENSE">135</int>
[20:38] <PeterDietz> <int name="LOGO-COLLECTION">45</int>
[20:38] <PeterDietz> <int name="TEXT">24</int>
[20:38] <PeterDietz> <int name="CC-LICENSE">3</int>
[20:38] <richardrodgers> good question robint - I think XMLUI only, but not sure. Another reason to close and reopen when tested
[20:39] <tdonohue> It looks like is was reported for both JSPUI & XMLUI (or at least the "screenshot" attached looks like JSPUI)
[20:39] <robint> richardrodgers: If you like I'll review this tomorrow and close if appropriate
[20:39] <mdiggory> PeterDietz: not too shabby
[20:39] <tdonohue> sounds good robint
[20:39] <richardrodgers> OK thanks robint
[20:40] <PeterDietz> my only issue thus far, is that I've built a reindexBitstreamName, and with 15M solr stats docs (8M bitstream hits), its taking to index this information into it.
[20:40] <tdonohue> next up, DS-615 assigned to Ben Bosman, but patched/reported by PeterDietz. Does this just need documentation?
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-615 ] - [#DS-615] Ability to perform maintenance on SOLR with solr.optimize - DuraSpace JIRA
[20:40] <mdiggory> PeterDietz: KevinVdV: I would recommend reviewing the work to see if its compitable with how we use Solr Stats...
[20:40] <PeterDietz> s/its taking to/its taking very long to/
[20:40] <kompewter> PeterDietz meant to say: my only issue thus far, is that I've built a reindexBitstreamName, and with 15M solr stats docs (8M bitstream hits), its taking very long to index this information into it.
[20:41] <KevinVdV> Well t.b.h. PeterDietz if we either go for your or my way the update script will take a long time
[20:41] * tdonohue ack, too many conversations at once.. :)
[20:41] <robint> tdonohue: yes, I emailed Peter today and we are awaiting a response from Ben
[20:41] <tdonohue> cool, we can move on then
[20:42] * mdiggory shuts mouth...
[20:42] <tdonohue> next up, our favorite DS-768. I think mdiggory & kshepherd seem to have this "under control". Am I right?
[20:42] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:42] <mdiggory> waiting to hear back from kshepherd
[20:43] <mdiggory> I released a snapshot of the dspace-cocoon-servlet-service jar that he commited changes to... just needs further testing before I do the formal release....
[20:43] <tdonohue> ok. let us know if more hands are needed. I'd gladly help out if more help is needed
[20:43] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:44] <tdonohue> thanks mdiggory & kshepherd. will be great to get this one fixed!
[20:44] <tdonohue> next up.. DS-985, reported by mdiggory. Is this something we still need to fix?
[20:44] <kompewter> [ https://jira.duraspace.org/browse/DS-985 ] - [#DS-985] JUnit Tests do not properly start the ServiceManager and Kernel - DuraSpace JIRA
[20:46] <mdiggory> KevinVdV: want this one too?
[20:46] <hpottinger> I'm willing to test 768, not sure how to use the snapshot, bet it's just a pom change, though
[20:46] <mdiggory> again, you;ve provided the patch.
[20:46] <mdiggory> hpottinger: thats right
[20:46] <KevinVdV> Well I'm always willing to get some more glory :)
[20:46] <KevinVdV> So I'll take it !
[20:47] <tdonohue> Ok, KevinVdV will claim Ds-985. Let us know if you need any help on it
[20:48] <KevinVdV> Ok thanks
[20:48] <tdonohue> Next is DS-987...I've just claimed this one. It was "fixed" by defaulting 'overwrite="true"' in "ant update". But, it likely still requires some documentation (a warning when setting 'overwrite=false'). I'll do it
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-987 ] - [#DS-987] By default, Solr Schemas & Configs don't upgrade properly & may cause instability - DuraSpace JIRA
[20:48] <tdonohue> Next is DS-1004 -- this will be rescheduled for post-1.8.0
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-1004 ] - [#DS-1004] Add optional reason text to tombstone page (XMLUI) - DuraSpace JIRA
[20:49] <tdonohue> Next is DS-1005 -- this is waiting on Documentation
[20:49] <kompewter> [ https://jira.duraspace.org/browse/DS-1005 ] - [#DS-1005] SWORD v2 implementation for DSpace - DuraSpace JIRA
[20:49] <tdonohue> Next is DS-1018, mdiggory has this mostly "fixed", I think?
[20:49] <kompewter> [ https://jira.duraspace.org/browse/DS-1018 ] - [#DS-1018] 'dspace-1.8.0-rc1-release.zip' is structured differently than 'dspace-1.8.0-rc1-src-release.zip' - DuraSpace JIRA
[20:49] * tdonohue sorry for the rush of issues...just wanting to "fast forward" a bit
[20:50] <mdiggory> Ds1005 the release process is done...
[20:50] <stuartlewis> Yep - thanks for fixing that mdiggory.
[20:51] <stuartlewis> Maybe assign DS-1005 to me, and I'll put some doco in?
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-1005 ] - [#DS-1005] SWORD v2 implementation for DSpace - DuraSpace JIRA
[20:51] <robint> Ds-1005 I've just left open until the docs are done
[20:51] <mdiggory> Ds1018 this is mostly done, I just need to switch to use the release of the dspace assembly plugin
[20:51] <robint> Ah! Thanks stuartlewis
[20:51] <tdonohue> stuartlewis, feel free to claim Ds-1005 and add docs. Thanks!
[20:52] <mdiggory> so, in relation to Ds-1005 I want to voice a concern....
[20:52] <tdonohue> ok, thanks mdiggory. Let me know if you need "testers" for Ds-1018
[20:52] <tdonohue> go ahead, mdiggory
[20:52] <mdiggory> And this isn't a criticism on all the hard work that went into v2
[20:53] <mdiggory> In SWORD v2, there is a feature for a sort of versioning where bundles in an item are backed up if it is enabled in dspace.cfg
[20:53] <mdiggory> this means that new bundles (with version numbers/dates) are spawned if an update is made via SWRODv2
[20:54] <stuartlewis> mdiggory: Not sure - best ask Richard (he wrote it), or I can dig through the code.
[20:54] <stuartlewis> Whoops - that wasn't a question?!
[20:54] <mdiggory> I'm worried about this creating unexpected results for those whoa re customizing DSpace
[20:55] <stuartlewis> What sort of unexpected results?
[20:55] <stuartlewis> SWORD v1 already uses bundles to store things such as the original deposit - don't think we've seen any issue with that.
[20:55] <tdonohue> yea, I just saw that option. It's the 'versions.keep=true' option (it's actually in the /config/modules/swordv2-server.cfg)
[20:55] <tdonohue> According to that config description, here's what it does...
[20:56] <mdiggory> Well, it creates a situation where new unexpected bundles are getting created and it sort of imposes a "sortof" solution in terms of versioning Items.
[20:56] <tdonohue> # when content is replaced, should the old version of the content be kept? This
[20:56] <tdonohue> # creates a copy of the ORIGINAL bundle with the name V_YYYY-MM-DD.X where YYYY-MM-DD
[20:56] <tdonohue> # is the date the copy was created, and X is an integer from 0 upwards.
[20:56] <tdonohue> versions.keep = true
[20:56] <tdonohue> So, it looks like it "spawns" multiple ORIGINAL bundles (with date suffixes)
[20:57] <stuartlewis> @see org/dspace/sword2/VersionManager.java
[20:58] <mdiggory> We currently are releasing the next iteration of NESCents Dryad codebase with Item Versioning. In this case Items are Versioned based on the startegy discussed in the Architectural Review.
[20:58] <stuartlewis> I don't these should be considered "versions" as such - more like "backups".
[20:58] <stuartlewis> Versioning isn't supported by SWORD, as in, "Roll back to version 5 please".
[20:59] <stuartlewis> These are more there as an archival utility to keep backups within the DSpace item.
[20:59] <mdiggory> What we are doing are real "Versions"
[20:59] <stuartlewis> In case someone overwrites something that they didn't mean to.
[20:59] <mdiggory> which can be reverted and/or viewed in their original form
[20:59] <tdonohue> maybe this is something the SWORDv2 docs can clarify then...sounds like a good point to make in docs
[21:00] <stuartlewis> Yep - we can do that when we document the config options.
[21:00] * robint_ (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[21:00] <tdonohue> makes sense, stuartlewis
[21:00] <mdiggory> I'm bringing this up because I see some promise in combining the two approaches
[21:01] <stuartlewis> Does this affect the implementations for 1.8, or should we have a special topic meeting post-1.8?
[21:01] <tdonohue> sounds like it could make a good post-1.8 discussion (or bring to dspace-devel immediately, and do a special topic after 1.8)
[21:02] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Ping timeout: 252 seconds)
[21:02] * tdonohue notices we are running over a bit
[21:03] <mhwood> And I need to leave...'bye!
[21:03] <tdonohue> One thing to mention (before people start having to leave). We didn't get to all the still, open issues. Issues Ds-1022 and above have all be reported during Testathon. There are many that haven't been claimed yet
[21:04] <tdonohue> So, if you have time in the coming weeks, please claim an issue or two & help out
[21:04] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has left #duraspace
[21:04] <mdiggory> Sorry, there was a distraction.
[21:04] <KevinVdV> If I find the time I can claim some of those but can't make any promises just yet....
[21:04] <tdonohue> Again, these open issues are all listed here: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[21:04] <kompewter> [ DevMtg 2011-09-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-21
[21:05] <hpottinger> tdonohue: is the testathon officially over? any objections to me running dspace_trunk code in place os RC1 code?
[21:05] <mdiggory> I'll try to document my concerns with the SWORD versionmanager soon, its not a show stopper for release though.
[21:05] <tdonohue> Testathon lasts until this Friday (end of day). You are welcome to update your test instance though , either way
[21:06] <tdonohue> Ok, I think that's everything I had for today. Anyone have last comments?
[21:07] <robint_> tdonohue: Thanks for going through the issues, very useful
[21:07] <hpottinger> tdonohue: OK, will borrow my testathon instance for DS-768 testing
[21:07] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[21:07] <tdonohue> no problem. Yea, I figured a quick run through might help get quick updates, robint :)
[21:07] <robint_> hpottinger: Thats a great idea !
[21:07] <tdonohue> hpottinger, sounds good. that's an excellent idea
[21:08] <tdonohue> ok, the official meeting is now closed. Feel free to hang around as long as you like! And, if you haven't tested anything yet, get out there and test for a few minutes! :)
[21:08] <richardrodgers> thanks all, bye
[21:09] * richardrodgers (~richardro@18.111.56.24) Quit (Quit: richardrodgers)
[21:09] <KevinVdV> Well I could always use some extra eyes on DS-959 I have added some more findings based on mdigorry's comments
[21:09] <kompewter> [ https://jira.duraspace.org/browse/DS-959 ] - [#DS-959] XMLUI login failure when using Tomcat 7.0.16 - DuraSpace JIRA
[21:12] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Quit: keithgilbertson)
[21:12] <tdonohue> thanks for the extra testing, KevinVdV. I think I may need to install my own Tomcat 7.0.16 and take a closer look as well.
[21:12] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[21:13] <KevinVdV> Feel free to do so & log anything you find tdonohue
[21:13] <tdonohue> of course
[21:14] <KevinVdV> Great
[21:14] * robint_ (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Ping timeout: 252 seconds)
[21:15] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[21:28] * keithgilbertson (~keithgilb@207.138.47.158) has left #duraspace
[21:29] * hpottinger has to run, bye folks!
[21:29] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[21:29] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has left #duraspace
[21:31] <KevinVdV> Need to run cya all
[21:32] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) Quit (Quit: KevinVdV)
[22:12] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.