Timestamps are in GMT/BST.
[0:59] * joaomelo (~DSpace@bl23-32-164.dsl.telepac.pt) Quit (Quit: joaomelo)
[5:19] * linux4u (~james@employed.library.emory.edu) Quit (Ping timeout: 264 seconds)
[5:20] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[6:47] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:47] -rajaniemi.freenode.net- *** Checking Ident
[6:47] -rajaniemi.freenode.net- *** Found your hostname
[6:47] -rajaniemi.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:47] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:47] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:12] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:57] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[14:28] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has joined #duraspace
[16:44] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has joined #duraspace
[16:44] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[17:10] * joaomelo (~DSpace@bl23-32-164.dsl.telepac.pt) has joined #duraspace
[17:48] * joaomelo (~DSpace@bl23-32-164.dsl.telepac.pt) Quit (Quit: joaomelo)
[19:37] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:47] * ryscher (98034473@gateway/web/freenode/ip.152.3.68.115) has joined #duraspace
[19:50] <tdonohue> Hi all, reminder that our DSpace Developers Meeting is in 10 mins here (that's one hour earlier for folks who just exited Daylight Savings). Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-11-07
[19:50] <kompewter> [ DevMtg 2012-11-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-11-07
[19:57] * KevinVdV (~Zombie_Ke@d54C154B1.access.telenet.be) has joined #duraspace
[19:59] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome. It's now time for our Weekly DSpace Developers mtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-11-07
[20:00] <kompewter> [ DevMtg 2012-11-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-11-07
[20:01] <tdonohue> Hopefully, those folks (like US/Canada & many others) who just left daylight savings time won't suddenly pop into this chat in one hour. I tried to remind folks plenty :)
[20:02] <robint> Remembered this week
[20:02] <tdonohue> In any case, the agenda today is the same as it's been in recent weeks....eventually updates/status on anything related to 3.0
[20:02] <tdonohue> that's right, robint...you all left daylight savings *last week* :)
[20:03] <tdonohue> that was supposed to be "essentially updates/status on 3.0"
[20:03] <tdonohue> In any case...is there anywhere in particular we want to start with 3.0 stuff? Things folks want to make known or need help/advice on?
[20:04] <hpottinger> There's an RC3 out... ready for testing...
[20:04] <robint> tdonohue: Just saw your update on the dspace.dir stuff, I'll have some time to look into it tomorrow
[20:04] <tdonohue> yep...we're into Testathon #2 this week...so, we'd encourage plenty more testing & reporting of issues!
[20:05] * helix84 (a@195.113.97.174) has joined #duraspace
[20:05] <tdonohue> robint...yea, that's the most I could come up with on your DS-1365 issue...hadn't had a chance to look into it much more than that. BTW, can we assign DS-1365 to you, robint?
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-1365 ] - [#DS-1365] The ability to filter the webapps web.xml files using -Ddspace.config was lost with the introduction of build.properties - DuraSpace JIRA
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-1365 ] - [#DS-1365] The ability to filter the webapps web.xml files using -Ddspace.config was lost with the introduction of build.properties - DuraSpace JIRA
[20:05] <robint> I'll grab it just now
[20:05] * tdonohue thanks kompewter for the repetition :)
[20:05] <tdonohue> ok, cool.
[20:06] <kompewter> tdonohue: You're welcome.
[20:06] <tdonohue> I also wanted to make folks aware of DS-1374, which I just discovered. Essentially, AIP Backup & Restore knows *nothing* about Item Versions, and therefore is only able to backup & restore the latest version (all other versions are lost)
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1374 ] - [#DS-1374] AIP Backup & Restore functionality does NOT backup/restore past versions of Items - DuraSpace JIRA
[20:06] <robint> Still an awful lot of bugs in 3.0
[20:08] <tdonohue> I consider Ds-1374 a significant bug...I was tempted to mark it as a blocker...but, decided to leave it as "Critical"... it will cause data loss (a horrible thing), but the system itself doesn't actually break (i.e. no errors actually happen)
[20:08] <KevinVdV> robint: there a lot of new features in 3.0 ;-)
[20:08] <mhwood> Sounds right.
[20:08] <helix84> hi RT, I have a small question for you, shall we let DS-1372 into 3.0? I'd say yes, see comments.
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1372 ] - [#DS-1372] Change OAI2.0 DSpaceMetadataExistsFilter to check for one or more fields - DuraSpace JIRA
[20:09] <robint> KevinVdV: very true
[20:11] <tdonohue> helix84 -- to me, it sounds like Ds-1372 is a bug, in that it actually causes issues with multiple author fields. I suspect this will effect other institutions as well
[20:12] <robint> helix84: Its fine by me if you and João are willing to look after the change
[20:12] <tdonohue> (esp. institutions who may have messy metadata with authors in either "dc.creator" or "dc.contributor.author", or other "dc.contributor.*" fields)
[20:12] <helix84> ok, marking it as a bug, just to avoid confusion in the future. thanks.
[20:13] <robint> Anyone with Oracle out there willing to look at DS-1372
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1372 ] - [#DS-1372] Change OAI2.0 DSpaceMetadataExistsFilter to check for one or more fields - DuraSpace JIRA
[20:13] <robint> ?
[20:13] <robint> Oops, sorry ! Wrong number
[20:13] <robint> DS-1370
[20:13] <hpottinger> Ds-1372 does sound like a bug fix, can put that in with 3.0 or with other 3-based releases... and I'm willing to look at anything that requires Oracle testing
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1370 ] - [#DS-1370] Errors in Oracle db script - DuraSpace JIRA
[20:14] <tdonohue> yea, I think hpottinger is the "usual suspect" when it comes to oracle stuff these days :) Though if anyone else uses Oracle, honestly we could use more Oracle support folks!
[20:15] * helix84 shivers
[20:15] <tdonohue> Here's our 3.0 issues, sorted with the "unassigned" ones at the top -- https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.0%22+AND+resolution+%3D+Unresolved+ORDER+BY+assignee+DESC%2C+priority+DESC
[20:15] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.0%22+AND+resolution+%3D+Unresolved+ORDER+BY+assignee+DESC%2C+priority+DESC
[20:15] * hpottinger hands helix84 a scarf.
[20:16] * helix84 hangs himself on the scarf
[20:17] <tdonohue> I notice that we have a handful here that are "unassigned" that seem to all be essentially the same issue (XMLUI + CC License display): DS-1329, DS-1323, DS-1354. Would anyone care to tackle all three with one fix?
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-1329 ] - [#DS-1329] CC License & Collection metadata on item pages Layout issues - DuraSpace JIRA
[20:17] <KevinVdV> *Notices he has the most issues assigned to him .... damn I need to get some work done*
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-1323 ] - [#DS-1323] CC Licenses on items link to nothing when displayed in XMLUI - DuraSpace JIRA
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-1354 ] - [#DS-1354] in XMLUI, the creative commons link does not address the creative-commons license, just the item page - DuraSpace JIRA
[20:17] <tdonohue> (Someone can also correct me if those aren't the same issue...they all just sound *very* similar)
[20:17] <helix84> IIRC, I prepared a fix, but I don't use CC, so I'd feel better if someone who does tested it
[20:18] <helix84> 1323 and 1354 are marked as dupes
[20:18] <tdonohue> helix84 -- where is your fix posted?
[20:19] <helix84> ah, that's the link issue, nevermind, i'll work on that
[20:19] <helix84> I didn't get to do it for a week :p
[20:20] <robint> Could we close the dupes ? Make ourselves feel better :)
[20:20] <tdonohue> ok, helix84, go ahead and assign them to yourself then
[20:20] <helix84> robint: no, i'll need to check them, they seem to address some other related stuff, too
[20:21] <helix84> done, all 3
[20:21] <tdonohue> I believe Ds-1323 (which I actually entered in) is an exact dupe of Ds-1354...so, it likely could be closed. Ds-1329 looks closely related, but I'm also not sure it's a 100% dupe
[20:21] <tdonohue> thanks, helix84
[20:21] <robint> Good work helix84 !
[20:22] * helix84 wonders if he can cheat some time off his sleep hours tonight...
[20:22] <tdonohue> Ok, looks like we're down to just 4 that are unassigned! The ever-present DS-1205....and then DS-1324, DS-1370 and DS-1373
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1205 ] - [#DS-1205] DSpace org.dspace.core.Context caching problem - DuraSpace JIRA
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1324 ] - [#DS-1324] BrowseEngine tries to use a non existent bi_*_dmap and bi_*_dis - DuraSpace JIRA
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1370 ] - [#DS-1370] Errors in Oracle db script - DuraSpace JIRA
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1373 ] - [#DS-1373] When logged in on item page, missing XMLUI key "xmlui.statistics.Navigation.view" - DuraSpace JIRA
[20:23] <tdonohue> Ds-1373 seems like a small one, if anyone wants an "easy fix". Just looks to be a missing key in messages.xml.
[20:23] <helix84> damn, we didn't put 1205 in in time for rc3!
[20:24] <robint> Could we reschedule DS-598 ? I don't think its going to get addressed
[20:24] <mhwood> I might suggest that we are too far into 3.0 release for 1205 to go in now.
[20:24] <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:25] <hpottinger> assigned 1370 to myself
[20:25] * helix84 wonders if he'd be skinned for suggesting another round of testathon
[20:25] <mhwood> Never mind, it looks like consensus that 1205 is ready.
[20:27] <tdonohue> I personally am extremely hesitant to run another round of testathon unless it's 100% necessary. I worry we're going to just wipe people out on "testing".
[20:27] <KevinVdV> I believe we need to fix more bugs before launching another testathon
[20:28] <hpottinger> maybe sneak it into master, and then sneak that onto demo? {ducks}
[20:28] <robint> DS-1205 has a pull request waiting
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-1205 ] - [#DS-1205] DSpace org.dspace.core.Context caching problem - DuraSpace JIRA
[20:28] <helix84> hpottinger: yes, that's what I was thinking
[20:28] <helix84> it's just that the testathon ends on friday
[20:29] <helix84> well, it's not like we're shutting demo down afterwards...
[20:29] <robint> We can still continue updating demo and testing
[20:29] <helix84> i'd say let's fix it now rather than wait for a year
[20:29] <hpottinger> honestly, 1205 should be easily tested, without anything as formal as a testathon
[20:29] <helix84> we may then hurry woth 3.1
[20:30] <robint> Shall we vote on 1205 ?
[20:30] <helix84> +1
[20:30] <robint> +1
[20:31] <tdonohue> I'm basically a +0.5 as I'm not sure how big an issue this really is
[20:31] <helix84> hardy?
[20:31] <hpottinger> oh, look, I've already volunteered to test it...
[20:31] <robint> hpottinger: thats why I voted in favour :)
[20:31] <helix84> i guess that settles it then
[20:32] <KevinVdV> Look at the code quickly, don't see any issues so +1
[20:33] <tdonohue> Small Sidenote: regarding testathon: I'll note that we've gotten a *lot* less hits on demo.dspace.org this week (2nd testathon) than during the first testathon, at least based on google analytics...the activity on demo is essentially trending downward each week since the initial testathon.
[20:34] <robint> tdonohue: once we have a version on demo that we are happy with we could organise an informal testathon
[20:34] * helix84 quickly checks whether his army of bots crashed
[20:34] <tdonohue> we've gone from 536 hits the first week of the first testathon...down to just 174 this week so far. Obviously the week isn't done yet though, so we can turn things around. Just wanted to note that I'm not sure as many folks are testing this week
[20:35] <hpottinger> Richard's caution has me feeling cautious as well...
[20:35] <tdonohue> & I agree, we could always do some "informal testathon" amongst ourselves to bang on things
[20:35] <robint> tdonohue: I am sure you are right, testing fatigue
[20:36] <mhwood> Or the stuff people worry about most is being addressed.
[20:36] <robint> hpottinger: "Note that this code has not been tested"
[20:36] <robint> That is a big warning sure enough
[20:36] <tdonohue> that's a bit of a scary note.
[20:36] <helix84> bah, I write them all the time
[20:37] <helix84> are you scaaared?
[20:37] <hpottinger> When RR says we should be careful, I step carefully... :-)
[20:37] <tdonohue> yea, the one thing that worries me about Ds-1205 is that, as RichardR states, it really could affect any other area of the codebase that uses Context (i.e. anything & everything).
[20:37] <robint> I am starting to wobble
[20:38] <helix84> I got really scared when hpottinger was on the merging spree
[20:38] <robint> Context is so critical to everything
[20:38] <helix84> look on the bright side - at least we'll have to fix it :)
[20:38] <helix84> or revert it
[20:38] <tdonohue> Yep, Context is used by every DSpace webapp (obviously) and also used by some that we've yet to release formally (REST-API). So, it's hard to say what the affects may be.
[20:39] <tdonohue> Honestly, how big of an issues is Ds-1205? Is it worth the risk?
[20:39] <tdonohue> (this is a real question...I don't know who all is being affected by Ds-1205)
[20:39] <mhwood> So maybe there's stuff not in the cache when it should be, and we lose performance? We could live with that. Caching stuff that shouldn't be is another story.
[20:40] <helix84> Joao: "I think this is a critical problem, mainly because it does not make sense (for me) to have crashing applications because of caching mechanism memory overusage."
[20:41] <tdonohue> helix84 -- yea, but one could argue -- if Joao is the only one seeing it, all he needs to do is install Richard's code on his own server. If no one else is seeing it that significantly (yet), maybe the widespread risk isn't worth it
[20:41] <helix84> i'm wondering whether this is related to an issue that has been getting long term coverage on dspace-tech - the need to restart tomcat periodically
[20:41] <tdonohue> I'm just asking myself...is this a *widespread issue*, or not
[20:42] <tdonohue> helix84 -- that's a good question. Not sure if they are connected or not though..
[20:43] <tdonohue> Cause the other option here is to....reschedule Ds-1205 for 3.1 or 4.0, and just tell folks to individually try out pull #114 if they see this issue. It's not ideal, I agree. But, this is another option.
[20:44] <robint> I confess I voted +1 in part because the fix came from Richard,
[20:44] <robint> Since he freely admits he hasn't tested it I'm inclined to change my vote
[20:44] <hpottinger> I'm OK with 1205 for 3.1, I restart Tomcat every night anyway :-)
[20:44] * helix84 facepalms
[20:45] <hpottinger> (that's my sardonic humor there, sorry)
[20:45] <tdonohue> I say this all knowing (like others do) that RichardR tends to have a very good feel of what the risks are & his recommendations are sound...he's one of our longest standing committers & been active for a long long time. When he is concerned about something, it does make you wonder if we need to take a step back for a moment
[20:46] <tdonohue> (his code is also usually extremely sound too...but it's his concerns that worry me)
[20:46] <helix84> how about letting hardy look at it and discuss it again next week?
[20:47] <tdonohue> I'm fine with folks trying it out and reporting back (we should do that anyhow)...there's no risk there :)
[20:47] <hpottinger> so, how to assess this code? if the repository is obviously pear shaped after applying it, that's one thing...
[20:48] <helix84> hey, it was you who said testing it would be easy :) I wouldn't know where to begin.
[20:48] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Ping timeout: 245 seconds)
[20:48] <tdonohue> hpottinger -- maybe get in touch with joao as to what he saw/sees? Or YourKit may be of help?
[20:49] <hpottinger> :-) applying the patch is easy and accessible to all of us... profiling is a good idea... but I don't know if my say-so is going to be enough on this one
[20:49] <tdonohue> YourKit should be able to give you a memory usage report, and you should be able to see what part is related to Context.
[20:50] * ryscher (98034473@gateway/web/freenode/ip.152.3.68.115) Quit (Ping timeout: 245 seconds)
[20:50] <hpottinger> thinks all the +1 voters should chip in :-)
[20:50] <tdonohue> hpottinger -- not sure either. Honestly more testing is a good thing, but the more I think about how nearly *every* class uses Context, the more I worry that there could be some unintended consequences
[20:51] <mhwood> The thing we most need tested is the one that's hard: did it silently lose an update?
[20:51] * helix84 fumbles for the keyboard to change his vote :)
[20:51] <helix84> mhwood: update?
[20:52] <mhwood> "Run-time exceptions will be thrown when a read-only context is used to update DSpaceObjects."
[20:52] * bllll (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:52] * bllll (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Client Quit)
[20:53] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:53] <robint> Got bombed out, did I miss anything interesting ?
[20:53] <helix84> http://irclogs.duraspace.org/index.php?date=2012-11-07
[20:53] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2012-11-07
[20:54] <hpottinger> I insinuated that +1s for 1205 oughta chip in with testing it :-)
[20:54] <helix84> i'm considering eating our own dogfood in production
[20:55] <hpottinger> helix84: I'm green-lighting an upgrade to a production repository based on 3.0, and thus will have a version running on staging pretty soon, can include pull 114 in that...
[20:56] <helix84> ok, let's do it and report back by another DevMtg
[20:56] <helix84> any tips what I should be watching out for?
[20:57] <helix84> is there danger only during item updates?
[20:57] <mhwood> Is this something that can be addressed by unit testing? By cutting away the rest of the product, can we completely surround the worrisome area economically and be assured that it is thoroughly exercised?
[20:58] <tdonohue> unit testing might help. That'd be a good first step...see if any unit tests fail with pull #114 in place. But, obviously as unit testing is lacking in most areas, it may not catch everything
[20:58] <mhwood> Well, we might need a new test or two.
[20:59] <tdonohue> we need a whole lot of new tests :)
[20:59] <tdonohue> essentially, yea I agree, mhwood
[20:59] <tdonohue> Ok...in any case...I want to note we are nearly out of time here. Are there any other 3.0 things we want to quickly touch on today?
[21:00] <tdonohue> anything else that folks need feedback/help on?
[21:01] <helix84> yes
[21:02] <helix84> Is DIM format still considered strictly internal? It's currently exposed by OAI.
[21:02] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has left #duraspace
[21:02] <helix84> DS-1367
[21:02] <kompewter> [ https://jira.duraspace.org/browse/DS-1367 ] - [#DS-1367] DIM schema - DuraSpace JIRA
[21:02] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[21:03] <tdonohue> DIM is "mostly internal", but yea...it's exposed via OAI, also exported via AIPs & similar. So it's not that internal these days, especially when folks want to easily move content from one DSpace to another (e.g. via OAI-PMH/OAI-ORE)
[21:03] <helix84> the original recommendation is here: https://wiki.duraspace.org/display/DSPACE/DSpaceIntermediateMetadata#DSpaceIntermediateMetadata-TheFormat
[21:03] <kompewter> [ DSpaceIntermediateMetadata - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpaceIntermediateMetadata#DSpaceIntermediateMetadata-TheFormat
[21:05] <tdonohue> I'm fine with Ds-1367. I think it's correct that DIM was initially conceived as an "internal" format...but, nowadays, it's use has expanded to OAI-PMH/OAI-ORE. In order to better support that sort of harvesting from one DSpace to another, I think we should have an XSD available for validation
[21:05] <tdonohue> but, that all being said, I haven't had a chance to look at Ds-1367 to ensure the XSD is completely right...
[21:05] <helix84> tdonohue: i suggest you put your +1 to the ticket
[21:06] <KevinVdV> Needs to run, until next week guys !
[21:06] * KevinVdV (~Zombie_Ke@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it!)
[21:07] <tdonohue> will do, helix84
[21:08] <tdonohue> One last thing to note...I suspect we may want to start asking about the status of some of these 3.0 tickets that have been just "sitting here". I suspect there may be some that either can be (a) closed easily, or (b) may need rescheduling/reassignment
[21:09] <tdonohue> By that last statement ... I'm mainly noting that it'd be good if someone (RT?) could take a quick glance at the 32 tickets we still have open (or at least the ones that haven't been updated in some time)....
[21:10] * helix84 wishes days would have 30 hours
[21:11] <tdonohue> I think that's everything I have for today though. We just need to continue testing & bug fixing. Hopefully we can get this release out soonish (current schedule states next Fri, Nov 15...not sure if that's attainable though or not)
[21:11] <helix84> tdonohue: at what intervals did minor versions tend to be released in the past?
[21:11] <hpottinger> release process is so smooth, anyone with git and maven (and a Linux or Windows box) can do it
[21:12] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has left #duraspace
[21:13] <tdonohue> helix84 -- minor releases have always been released "as needed" and not on a specific schedule. Sometimes they are as quickly as one month later...other times it's more like 3+ months later. It all depends on when we find a bug that we feel needs to be fixed ASAP
[21:14] <helix84> tdonohue: and does RT stay responsible for the minor releases?
[21:14] <tdonohue> You can find more recent (last 5+yrs) release dates based on the dates of the folders in SourceForge: http://sourceforge.net/projects/dspace/files/DSpace%20Stable/
[21:14] <kompewter> [ DSpace - Browse /DSpace Stable at SourceForge.net ] - http://sourceforge.net/projects/dspace/files/DSpace%20Stable/
[21:14] <hpottinger> it's usually a month after someone says, "say, are we going to have a .1 release?"
[21:15] * mdiggory (~mdiggory@rrcs-74-87-47-118.west.biz.rr.com) has joined #duraspace
[21:15] <helix84> welcome mdiggory
[21:15] <tdonohue> helix84 -- this is the first time we've ever had an RT. The RT for 3.1 need not be the same folks as the RT for 3.0.
[21:15] <mhwood> Must go. Thanks, all.
[21:15] <mdiggory> Hello
[21:15] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:16] * sands (~sands@dhcp-18-111-22-93.dyn.mit.edu) has joined #duraspace
[21:16] <helix84> LOL, DST FTW!
[21:17] <tdonohue> Generally though, .1, .2 releases are much easier/quicker & smaller. So, the RT roles should be much smaller....usually the release tasks are easier to share amongst the committers as it is...you mostly just need some testers, a person to push the release button & someone to announce it
[21:17] <helix84> mdiggory: would you care to try some sitemap magic?
[21:17] <mdiggory> ?
[21:17] <tdonohue> Hi mdiggory & sands -- looks like you two forgot about the meeting time-change (cause of USA leaving daylight savings). Our 20:00UTC meeting is now at 3pm EST
[21:17] <tdonohue> so, we're just closing up
[21:18] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) Quit (Quit: Leaving.)
[21:18] <mdiggory> Ah, now I understand
[21:18] <helix84> mdiggory: https://jira.duraspace.org/browse/DS-1017
[21:18] <kompewter> [ [#DS-1017] mobile dspace theme - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1017
[21:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1017 ] - [#DS-1017] mobile dspace theme - DuraSpace JIRA
[21:18] <sands> rrrright. and i was in a meeting because of the shift anyway, so, oh well. apologies.
[21:18] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has joined #duraspace
[21:19] <helix84> mdiggory: basically, the mobile theme is hard-wired to sit on mobile.example.org, we'd like to support example.com/mobile/, too
[21:19] <tdonohue> no problem...check the logs for the discussion for today -- http://irclogs.duraspace.org/index.php?date=2012-11-07 I'll be lurking around here for a while if there's anything left to discuss/bring up
[21:19] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2012-11-07
[21:20] <mdiggory> helix84: at first blush that seems reasonable
[21:20] <helix84> btw thanks for the info, tdonohue!
[21:20] <helix84> mdiggory: we tried and we burned
[21:20] <hpottinger> pulled 114, am running mvn test -Dmaven.test.skip=false right now
[21:21] <mdiggory> Likewise, I had a quick question concerning folks experience with item versioning in the testathon and demo, are there any concerns cropping up with that we need to be aware of?
[21:21] <helix84> yep, a serious one just today
[21:21] <helix84> DS-1374
[21:21] <kompewter> [ https://jira.duraspace.org/browse/DS-1374 ] - [#DS-1374] AIP Backup & Restore functionality does NOT backup/restore past versions of Items - DuraSpace JIRA
[21:21] <mdiggory> helix84: be aware that we now have Cocoon configured by Spring WebMVC, not the other way around
[21:22] <helix84> mdiggory: that's chinese to me :(
[21:22] <tdonohue> mdiggory: RE: item versioning..as helix84 just posted, it's not working with AIP Backup & Restore.
[21:23] <mdiggory> We did work to detect versioned handle identifiers in AIP and reconstruct the version history.
[21:23] <hpottinger> FYI, all tests pass after applying Pull 114
[21:24] <tdonohue> mdiggory -- where is that work? I didn't see any changes to the AIP codebase in 3.0
[21:24] <tdonohue> essentially, AIPs in 3.0 look identical to AIPs in 1.8...so the old versions get lost
[21:24] <tdonohue> thanks for noting hpottinger
[21:25] <mdiggory> Did the test use https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/identifier/VersionedHandleIdentifierProvider.java#L187
[21:25] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/identifier/VersionedHandleIdentifierProvider.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/identifier/VersionedHandleIdentifierProvider.java#L187
[21:26] <tdonohue> mdiggory...what is the "AIP service"? Is this something new/undocumented? I'm just using the same old AIP Backup & Restore commands from 1.8. They work in 3.0, but the AIPs that are exported contain NO version info
[21:26] <tdonohue> hence...all version info is lost, since DSpace 3.0 doesn't know how to write Item Versions into AIPs
[21:27] <tdonohue> (I hope that makes sense... let me know if it doesn't)
[21:27] <mdiggory> well, 1.8 AIP do not contain versioned handles.
[21:27] <tdonohue> right, obviously.
[21:28] <tdonohue> but, 3.0 AIPs also do not seem to contain versioned handles
[21:28] <mdiggory> The only difference with a 3.0 AIP for a version of an item is that its handle contains versioning detail
[21:29] <tdonohue> mdiggory - Are you saying that *each version* should have its own AIP zip package? Not sure I understand that statement?
[21:29] <mdiggory> Correct
[21:30] <mdiggory> But I am also saying that the whole system needs to be using the VersionedHandleIdentifierProvider for it to work. This needs to be confirmed
[21:30] <tdonohue> I'm almost certain it is not
[21:30] <mdiggory> The default is autowired... and the example configuration is here
[21:30] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace/config/spring/api/versioning-service.xml
[21:30] <kompewter> [ DSpace/dspace/config/spring/api/versioning-service.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/spring/api/versioning-service.xml
[21:31] <mdiggory> but the example that is commented out currently doesn't use the right provider... I need to look at the autowiring and confirm there as well.
[21:31] <mdiggory> yep... its incorrect here
[21:31] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml
[21:31] <kompewter> [ DSpace/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml
[21:32] <tdonohue> I'm also not sure that having a separate AIP for each version would actually *work*, as you change the "handle" each time you version an item (e.g. 123/45 becomes 123/45.1 becomes 123/45.2)...this means on every item change you have to regenerate AIPs for every single version of that item and re-link them together between AIPs and duplicate the content files in each AIP
[21:32] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml#L60
[21:32] <kompewter> [ DSpace/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml#L60
[21:32] <mdiggory> there would be separate new AIP for each version because every version is a true item
[21:32] <tdonohue> I think the correct solution for AIPs + Item Versions, is to generate ONE AIP, which describes all the version of that document
[21:33] <mdiggory> One Item = One AIP
[21:33] <tdonohue> mdiggory -- but, that's a bad model for AIPs....you're duplicating bitstreams in every AIP (i.e. if one item has 3 bitstreams and 30 versions, you duplicate those 3 bitstreams in 30 AIPs)
[21:34] <tdonohue> it leads to a ton of storage necessary to keep around AIPs
[21:36] <mdiggory> The one thing we could not guarantee is that the conservation of files within the BitstreamStorageManager will happen on restoration. Because there is no storage of the internal id of the Bitstream in the AIP
[21:37] <mdiggory> and conservation is based on multiple Bitstreams referencing the same internal id
[21:37] <mdiggory> and thus the same content file.
[21:37] <tdonohue> mdiggory -- if I'm understanding correctly, that issue would be fixed if you stored *all versions* in one AIP...they could just reference the same content file in that AIP package, as needed
[21:38] <mdiggory> so, yes it is not a perfect model yet. At least until theres some work to allow the manifests and content to be stored separately
[21:38] <mdiggory> and transferred separately. (IE similar to fedora)
[21:39] <mdiggory> tdonohue: that is plausible, but breaks the model of each version being its own Item
[21:39] <mdiggory> how are you going to store the multiple METS manifests?
[21:40] <tdonohue> not sure how it does, mdiggory...once a version is in an AIP, it's now longer in DSpace. You just *restore* each version as a new Item in DSpace.
[21:41] <tdonohue> I was actually anticipating the AIP would have a similar structure to 1.8....you'd have one METS manifest, which describes *all versions* & holds all metadata via its Sitemap...and then any associated files. Alternatively, you could have a separate METS manifest for each version and just link them all together
[21:41] <mdiggory> Yes, each version is totally intended to be a true item in DSpace, such that it can be resolved via its handle, the versioning is only a relationship between items.
[21:42] <mdiggory> and internally in the assetstore, between bitstreams.
[21:42] <tdonohue> but, either way...the "AIP package" as a whole (whether it contains one METS or multiple METS) would describe the Item "as a whole" (i.e. all versions). When you restored that AIP, it would auto-restore all Item versions
[21:43] <mdiggory> this is your proposal? It is not what is implemented.
[21:43] <tdonohue> (so, when I'm talking "AIP package"...I'm talking about a Zip package which contains one or more METS + content files)
[21:44] <tdonohue> mdiggory -- yea, that's my proposal, cause otherwise, I believe (unless I'm totally misunderstanding) you will currently have ballooning storage costs associated with AIPs each time you version an item.
[21:44] <tdonohue> (but note, I still personally don't understand how it currently works anyways...cause, I cannot get DSpace 3.0 to generate AIPs for versions at all.)
[21:46] <mdiggory> tdonohue: ok, I identified one problem in https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml#L60
[21:46] <kompewter> [ DSpace/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml#L60
[21:47] <mdiggory> Give me a moment and I will see how to improve this configuration
[21:49] <tdonohue> Sure, no problem :) It might help me better understand how it's all expected to work anyhow... I'm hoping I'm somehow wrong about my "ballooning storage costs" worries.
[21:53] * joaomelo (~DSpace@bl23-32-164.dsl.telepac.pt) has joined #duraspace
[21:53] * joaomelo (~DSpace@bl23-32-164.dsl.telepac.pt) Quit (Client Quit)
[21:53] * sands (~sands@dhcp-18-111-22-93.dyn.mit.edu) Quit (Quit: sands)
[21:53] <mdiggory> Ok, so with the demo, we do not get versioned handles on new versions, but instead completely unique handles?
[21:53] * joaomelo (~DSpace@bl23-32-164.dsl.telepac.pt) has joined #duraspace
[21:54] <mdiggory> or do we get correctly versioned handle identifiers?
[21:54] <tdonohue> I don't understand what you mean by "versioned handles". are you talking about 1234/45.1 and 1234/45.2?
[21:54] <mdiggory> yes that is a versioned handle
[21:55] <tdonohue> then..yes, on demo.dspace.org, we are getting versioned handles each time you version an Item (trying to find an example)
[21:55] <mdiggory> as opposed to 1234/45 and 1234/46,...
[21:56] <mdiggory> ok, then this configuration is correct, the right Identifier service is enabled here:
[21:56] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml#L31
[21:56] <kompewter> [ DSpace/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/spring/spring-dspace-core-services.xml#L31
[21:57] <tdonohue> yea, here's an example from demo server: http://demo.dspace.org/xmlui/handle/10673/138
[21:57] <kompewter> [ Item to be versioned - Original Version ] - http://demo.dspace.org/xmlui/handle/10673/138
[21:57] <tdonohue> To be clear, I'm also seeing those "versioned handles" on my local DSpace 3.0. But, when I do the AIP export, there are no versioned handles in any AIPs
[21:58] <mdiggory> and is auto wired into the IdentifierService, which theDefaultItemVersionProvider used in the VersioningService uses to create and lookup handles
[21:58] <mdiggory> what are the handles the AIP gets?
[21:59] <tdonohue> The AIPs all export fine...they just get the main handles of the Items. Essentially what is exported is only an AIP representing the LATEST VERSION of any versioned item.
[21:59] <mdiggory> no, that doesn't sound right
[21:59] <tdonohue> So, if I have an Item 123/45 with versions 123/45.1 and 123/45.2, all I end up with is an AIP that represents 123/45
[22:00] <tdonohue> yep..exactly, it's a bug, which is why I put in DS-1374 describing that issue
[22:00] <kompewter> [ https://jira.duraspace.org/browse/DS-1374 ] - [#DS-1374] AIP Backup & Restore functionality does NOT backup/restore past versions of Items - DuraSpace JIRA
[22:00] <mdiggory> Right, so all the versions would be in different AIP but have the same canonical handle.
[22:01] <mdiggory> you cannot backup 123/45.1 and 123/45.2 separately and get different AIP?
[22:01] <mdiggory> 123/45 should only be the latest version
[22:01] <mdiggory> aka 123/45.2
[22:01] <tdonohue> I can try and specifically export 123/45.1 and see what happens
[22:02] <tdonohue> the problem is that you shouldn't have to specifically export every single AIP by listing each one out...that'd be impossible to manage :)
[22:02] <mdiggory> I think the problem is that AIP exporter isn't traversing the versions as well, because it was never extended to do so.
[22:02] <tdonohue> Ok, so that did work... If I specifically say...just give me "123/45.1", then I get an AIP for that version
[22:03] <tdonohue> right..it sounds like the traversiong isn't working at all
[22:03] * scottatm_ (~scottatm@adhcp218.evans.tamu.edu) has joined #duraspace
[22:03] <tdonohue> err..traversing
[22:04] <mdiggory> we could adjust the code to traverse the versions, and package into individual or a group AIP (that could be configurable)
[22:05] <mdiggory> restoration would need to do the same.
[22:05] <tdonohue> but, this test has proven to me that you would end up with ballooning storage costs...ugh.... essentially, if an Item's "base" AIP is 100KB in size, and you have 10 versions, it's gonna take up ~1MB of space (as it's duplicating all AIP contents for each version)
[22:05] <mdiggory> but already restoration of a AIP for a version should attempt to populate the version history correctly.
[22:06] <tdonohue> yea...I think we'd want to have a "group AIP" if that's possible, to avoid the duplication of content files (bistreams) which cause the ballooning storage cost problem
[22:06] * joaomelo (~DSpace@bl23-32-164.dsl.telepac.pt) Quit (Read error: Connection reset by peer)
[22:06] <mdiggory> tdonohue: only if we don't adjust for versions when restoring and link to the internal id appropriately.
[22:07] <tdonohue> mdiggory -- I think you are misunderstanding me.. The "ballooning storage costs" is in the *storage* of the AIPs....so, if you backup DSpace AIPs to a harddrive or say, DuraCloud, your storage costs is going to go up with item versioning...as you will be storing most bitstreams multiple times in multiple AIPs
[22:08] * scottatm (~scottatm@adhcp218.evans.tamu.edu) Quit (Read error: Connection reset by peer)
[22:08] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) Quit (Ping timeout: 264 seconds)
[22:08] * joaomelo_ (~DSpace@144.64.32.164) has joined #duraspace
[22:08] * scottatm_ is now known as scottatm
[22:08] * joaomelo_ is now known as joaomelo
[22:08] <mdiggory> tdonohue: I think you already know I don't like the zip archive approach for AIP, especially int he case of storing into Duracloud
[22:08] <mdiggory> but your concern is valid in that case.
[22:10] <tdonohue> No matter how you plan to store AIPs (in Zip or not), the problem is the duplication of the bitstreams... obviously though, if things were stored "unzipped" you might be able to interlink bitstreams better.... But, by that model it seems like in a "zipped AIP" would should be thinking about ONE AIP to describe *all versions* of an Item
[22:11] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has joined #duraspace
[22:12] <tdonohue> So, I guess the question here is... is there any plan for @mire to work on one or more of these issues (we've identified several here already)? Or should I be looking into this more deeply myself?
[22:12] <mdiggory> One of the current recommendations on our side is that Versioning might be "disabled" by default and turned on if wanted, giving us a maintenance release or two to correct for discrepancies like this
[22:13] <mdiggory> similar to the approach we've taken with Discovery
[22:13] <tdonohue> right, that could make some sense perhaps.
[22:13] <tdonohue> Is that really easily "doable" though? If so, I wonder if we should bring this up amongst the Committers as a whole (likely via email)
[22:14] <tdonohue> that way we can get the discussion started about which direction we want to take here
[22:14] <mdiggory> however, if you feel that you want to explore getting the versions into the Item AIP so you have a hand in getting the design right, we are open to that too.
[22:14] <tdonohue> I'd be interested in that later option either way...whether versioning is "on" or "off" by default.
[22:15] <helix84> mdiggory: sorry for jumping into your discussion, but I wanted to ask you before you leave - would you mind if I assigned DS-1375 to you? You can "unassign" it at any time but I hoped you could take a look.
[22:15] <kompewter> [ https://jira.duraspace.org/browse/DS-1375 ] - [#DS-1375] mobile dspace theme should be accessible under the "/mobile" URL - DuraSpace JIRA
[22:15] <tdonohue> I think the big question in my mind though is -- how much longer is it gonna take to "get the design right" on AIPs + Versioning...and is it worth the wait for 3.0, or do we offer more options to disable versioning in 3.0 if you really want AIPs, etc
[22:15] <mdiggory> by on or off, my assumption is that the aspect is just disabled so its not available in the UI
[22:16] <mdiggory> I don't think we got this into JSPUI yet did we?
[22:16] <tdonohue> oh, ok. gotcha mdiggory -- so it's just "off" in that there's no way to actually call the code from the UI. I don't think it's in the JSPUI yet
[22:17] <tdonohue> yea, versioning is in XMLUI obviously: http://demo.dspace.org/xmlui/handle/10673/138 , but not in JSPUI for the same item: http://demo.dspace.org/jspui/handle/10673/138
[22:17] <kompewter> [ Item to be versioned - Original Version ] - http://demo.dspace.org/xmlui/handle/10673/138
[22:17] <kompewter> [ DSpace Demo Repository: Item to be versioned - Original Version ] - http://demo.dspace.org/jspui/handle/10673/138
[22:21] <helix84> mdiggory: sorry for jumping into your discussion, but I wanted to ask you before you leave - would you mind if I assigned DS-1375 to you? You can "unassign" it at any time but I hoped you could take a look.
[22:21] <kompewter> [ https://jira.duraspace.org/browse/DS-1375 ] - [#DS-1375] mobile dspace theme should be accessible under the "/mobile" URL - DuraSpace JIRA
[22:22] <mdiggory> helix84: one way we've extended the theme selection in other cases is to allow for vhosts in xmlui.xconf
[22:23] <mdiggory> I can't help but wonder if that could be extended to User Agents
[22:23] <mdiggory> then the same URI isued for the site, but based on the Agent, you see something different
[22:24] * helix84 (a@195.113.97.174) Quit (Read error: Connection reset by peer)
[22:25] * helix84 (a@195.113.97.174) has joined #duraspace
[22:25] <helix84> sorry, power outage
[22:26] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[22:27] <helix84> good idea, but that would eliminate the possibility of testing the mobile version with browsers not marked as mobile
[22:28] <mdiggory> thats a parameter you can use in query strings.
[22:28] <tdonohue> perhaps there's a way to override the useragent default? "?mobile=true" or "?mobile=false"
[22:28] <helix84> what? user agent?
[22:28] <mdiggory> no, the theme to be enabled
[22:29] <helix84> ah, right. but that's per-request, not per-session
[22:29] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L1714
[22:29] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L1714
[22:30] <helix84> that's another issue, but is there a way to change themepath to be remembered from one request to another?
[22:30] <tdonohue> yea, those querystring options are just per-request right now.
[22:30] <mdiggory> session or cookie...
[22:30] <helix84> could be just remembering the GET parameter, something like input type=hidden
[22:31] <mdiggory> you;d need to change a whole lot of links
[22:31] <helix84> i'm saying that because that would be explicit
[22:34] <mdiggory> I'd say a combo of UserAgent and Session, write a change into the theme selector that detects the mode via user agent or request parameter and stores it in the session. Put a link in the footer to switch between themes
[22:34] <helix84> what would the link be?
[22:35] <mdiggory> tdonohue: perhaps there's a way to override the useragent default? "?mobile=true" or "?mobile=false"
[22:35] <helix84> just javascript call to change the value of the cookie?
[22:37] <helix84> grr, detectmobile.js is obfuscated, don't they know cocoon can do that aoutomatically...
[22:38] <helix84> https://github.com/miohtama/detectmobile.js/blob/master/src/detectmobile.js
[22:38] <kompewter> [ detectmobile.js/src/detectmobile.js at master · miohtama/detectmobile.js · GitHub ] - https://github.com/miohtama/detectmobile.js/blob/master/src/detectmobile.js
[22:38] <helix84> seems it has force-mobile
[22:39] <mdiggory> cookie seems ok to me too
[22:39] <mdiggory> but you need to work on the business logic in the theme selector.
[22:40] <helix84> yes, i'm just thinking that there will be a problem somewhere with theme switchich
[22:40] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/ThemeMatcher.java#L61
[22:40] <kompewter> [ DSpace/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/ThemeMatcher.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/ThemeMatcher.java#L61
[22:40] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has left #duraspace
[22:42] <helix84> i think there's a clash of responsibilities here of the theme matcher and detectmobile.js
[22:42] <helix84> i mean would be
[22:46] <helix84> regarding your suggestion about user agent detection - that would have negative effect on caching proxies, as mentioned here: https://github.com/miohtama/detectmobile.js/blob/master/README.rst
[22:46] <kompewter> [ detectmobile.js/README.rst at master · miohtama/detectmobile.js · GitHub ] - https://github.com/miohtama/detectmobile.js/blob/master/README.rst
[22:47] <helix84> so cocoon can't help us here with rewriting links?
[22:48] * tdonohue doesn't want to interrupt this discussion...just noting mdiggory that I added a summary of our AIP + Item Versioning discussion as a comment on DS-1374.
[22:48] <kompewter> [ https://jira.duraspace.org/browse/DS-1374 ] - [#DS-1374] AIP Backup & Restore functionality does NOT backup/restore past versions of Items - DuraSpace JIRA
[22:48] * tdonohue is heading out shortly though...good luck helix84 & mdiggory on this mobile theme stuff
[22:49] <helix84> i think we're stuck and we're just enumerating options here...
[22:50] <tdonohue> (makes sense...you could always summarize options in JIRA or on dspace-devel to see if it generates any more ideas/volunteers)
[22:50] <tdonohue> gotta head out...thanks for the discussion today all!
[22:50] <helix84> tdonohue: suggestion regarding the AIP issue - you may want to create subtasks for the 2 separate issues,
[22:51] <tdonohue> helix84 -- yea, will do when I get a chance...just wanted to get them summarized first
[22:51] <helix84> putting both in like this didn't work well for me in the "display bitstream permissions" issue
[22:51] <helix84> sure, good night
[22:54] * tdonohue (~tdonohue@c-50-129-94-92.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.