Timestamps are in GMT/BST.
[1:14] * ryscher (~chatzilla@dhcp192.nceas.ucsb.edu) Quit (Ping timeout: 252 seconds)
[4:35] * ryscher (~chatzilla@wsip-72-215-170-58.sb.sd.cox.net) has joined #duraspace
[5:21] * ryscher (~chatzilla@wsip-72-215-170-58.sb.sd.cox.net) Quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
[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
[11:28] * fasseg (~fas@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[13:30] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:03] * fasseg (~fas@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[15:09] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:12] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:25] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:27] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[17:00] <tdonohue> Hi All. My DSpace "Office Hours" is starting now. I'll be lurking here while I do some work. Feel free to ping me if you have any questions/topics to discuss around DSpace. https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[17:00] <kompewter> [ DSpace Office Hours - Tim Donohue - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[17:32] * kshepher1 (kim@ec2-184-73-177-234.compute-1.amazonaws.com) has joined #duraspace
[17:37] * ChanServ (ChanServ@services.) Quit (*.net *.split)
[17:37] * kshepherd (kim@ec2-184-73-177-234.compute-1.amazonaws.com) Quit (*.net *.split)
[17:37] * scottatm (~scottatm@adhcp218.evans.tamu.edu) Quit (*.net *.split)
[17:38] * scottatm (~scottatm@adhcp218.evans.tamu.edu) has joined #duraspace
[17:42] -tomaw- [Global Notice] Hi all. One of our sponsors has some issues at the moment which resulting in a lack of NickServ, ChanServ and friends. We're investigating now!
[17:44] * scottatm (~scottatm@adhcp218.evans.tamu.edu) Quit (*.net *.split)
[17:45] * scottatm (~scottatm@adhcp218.evans.tamu.edu) has joined #duraspace
[19:19] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:28] * vtkeithg (~vtkeithg@vtkeithg.lib.vt.edu) has joined #duraspace
[19:31] <vtkeithg> Has anyone worked on http partial content/range requests for DSpace bitstreams?
[19:34] <vtkeithg> or, has anyone found a way to play embedded videos from DSpace in iPads?
[19:34] -christel- [Global Notice] Hi all, normal services (harr, see what I did there?) should return momentarily -- unfortunately one of our major sponsors suffered loss of power and a grue had eaten the UPS! Stuff is starting to return and we shall soon be back in business. Thank you for being patient.
[19:35] <tdonohue> Hi vtkeithg -- searching around a bit. I don't know of anyone offhand
[19:36] <vtkeithg> thanks
[19:37] <tdonohue> interesting. Found this commented out section in the XMLUI codebase: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/cocoon/ItemExportDownloadReader.java#L170
[19:37] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/cocoon/ItemExportDownloadReader.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/cocoon/ItemExportDownloadReader.java#L170
[19:38] <vtkeithg> hmmm - I hope it's that easy. :)
[19:39] <vtkeithg> Suppose I can try it today
[19:40] <tdonohue> no idea if it'll be that easy, to be honest. Never tried it. That bit of code just popped up when I search google for "http partial content/range requests, dspace" (without the quotes)
[19:42] <tdonohue> you could also try asking around on dspace-devel. I know there have been other folks trying to do some embedded video work with DSpace, but I'm not sure if anyone has anything that works well
[19:43] <vtkeithg> Thanks, Tim.
[19:43] <tdonohue> you're welcome!
[19:47] * helix84 (a@195.113.97.174) has joined #duraspace
[19:50] <tdonohue> Hi all, DSpace Devel Mtg is in approx 10 mins. Agenda today is basically 3.0 stuff : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-22
[19:50] <kompewter> [ DevMtg 2012-08-22 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-22
[19:56] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:56] <KevinVdV> Hi everybody
[19:56] <vtkeithg> hi
[19:58] * bollini (~chatzilla@host216-210-dynamic.37-79-r.retail.telecomitalia.it) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developer Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-22
[20:00] <kompewter> [ DevMtg 2012-08-22 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-22
[20:01] <tdonohue> Today we'll be concentrating on 3.0 tasks again (since we are nearing our "Submission Deadline" and "Feature Freeze")
[20:02] <tdonohue> First off though, I wanted to remind everyone that the 3.0 Submission Deadline is this Friday (Aug 24). Any code that is not submitted by then (preferrably via Pull Request) will NOT be considered for 3.0
[20:02] <tdonohue> (The only exception would be if you've talked with the 3.0 Release Team and they've given you an extension for whatever reason)
[20:03] * bollini (~chatzilla@host216-210-dynamic.37-79-r.retail.telecomitalia.it) Quit (Ping timeout: 245 seconds)
[20:03] * bollini (~chatzilla@host216-210-dynamic.37-79-r.retail.telecomitalia.it) has joined #duraspace
[20:03] <tdonohue> If there are any questions on the "Submission Deadline" let us know.
[20:05] <tdonohue> Hmm...noticing we seem to have a "smallish" crowd today, especially in terms of Release Team members... Hopefully we'll have others pop in along the way
[20:05] * bollini (~chatzilla@host216-210-dynamic.37-79-r.retail.telecomitalia.it) Quit (Read error: Connection reset by peer)
[20:06] <PeterDietz> just clarification, feature freeze means no new features after the deadline, but any bug-fixes (related or unrelated to a Pull Request) are allowed in
[20:06] <tdonohue> One question to ask. Does anyone have any code that is still planning to be submitted via a Pull Request (before Friday)? Anything we need to keep in mind in the coming days
[20:06] * bollini (~chatzilla@host216-210-dynamic.37-79-r.retail.telecomitalia.it) has joined #duraspace
[20:07] <tdonohue> Correct, PeterDietz. Thanks for correcting my typing :) We're talking about now new features. Bug fixes (via pull requests or otherwise) are free to continue to be submitted all the way up until the final weeks/days of 3.0 release
[20:07] <helix84> yes, i have two pieces coming up
[20:07] <helix84> one is DS-1084
[20:07] <bollini> (checking irclogs as I have had trouble with my internet connection)
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1084 ] - [#DS-1084] Handle authority and confidence fields in Bulk Editing - DuraSpace JIRA
[20:07] <helix84> and the other one is the combined LDAP auth
[20:08] <tdonohue> ok, good to know helix84. Any concerns about getting the code submitted by Friday? Or is everything looking like it should be ready on time?
[20:09] <bollini> I have some other contributions that we (CILEA) want to share but we are not able to meet the deadline
[20:09] <helix84> well, the code is out there in jira, i just need to finish testing and make the pull requests
[20:09] <helix84> i�ve had only minor bumps on the road
[20:10] <tdonohue> ok, sounds good, helix84
[20:10] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:11] <bollini> can I ask a question about DS-1084?
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1084 ] - [#DS-1084] Handle authority and confidence fields in Bulk Editing - DuraSpace JIRA
[20:11] <tdonohue> bollini: you are still welcome to share code after the 3.0 deadline. It's just much more likely that we'd suggest releasing the code as a "third-party addon" (i.e. installed separate from DSpace)
[20:11] <helix84> i found another smallis issue today - command line options to create-administrator could be rewritten in a more sane way (see today's dspace-tech thread). I'd do it but I'll be concentrating on these two + XOAI, so if anyone has some free time before friday, you might want to take a look.
[20:12] <tdonohue> if your question is a quick one, bollini, you are welcome to ask it
[20:12] <bollini> tdonohue: oh yes I know, but there is much appeal to contribute something if this will go in an official release
[20:12] <helix84> bollini: I'm listening
[20:12] <hpottinger> also note that crazy people like me sometimes like to mix and match and run unofficial code, so do share it, who knows, I may run it in production :-)
[20:13] <bollini> helix84: do you know if there is a way to ask the CVS import to check for a best match using the authority plugin?
[20:14] <tdonohue> bollini -- if there's something you really want to see in the official release, you should either try to meet the deadline or email dspace-release list about getting an extension (i.e. if the code is small or contained enough, there can be exceptions to the deadline. But you need to ask first)
[20:14] <helix84> bollini: i have to answer mu. that question doesn't make sense. there's no code choosing anything during import, it just takes what you specify and puts it into the DB.
[20:15] <helix84> i's you have this field: "Bollini, Andrea::xyz123123132::600"
[20:15] <bollini> helix84: now if you import a metadata that is authority controlled, the code call the "simple" addMetadata methods that internally call the getBestMatch of the authority plugin so there is a chance that the values in CSV are changed to match values taken from the authority list
[20:15] <mdiggory> bollini: It would also seem appropriate that we have (1) a curation task, (2) a consumer and/or (3) a CLI command that would attempt to refine authority values for configured fields.
[20:15] <helix84> it puts a record into the metadatavalue table columns text_value, authority, confidence
[20:16] <helix84> i haven't tested with an authority plugin, in my case that gets done outside dspace :/
[20:16] <bollini> we should have a way to reproduce current behavior (like Bollini, Andrea::auto)
[20:16] <helix84> but ask Keiji, he'll know
[20:17] <helix84> of course, it's backwards compatible, so if there are no ::, it works like before
[20:17] <helix84> you can have it on one line and not on another
[20:17] <mdiggory> but I'll also note that, this seems more like application logic and not actual alteration of the item... meaning, one would probibly want something more like a report or "advice" that might later be actionable
[20:18] <bollini> but we also need the inverse... we need to be able to force value without authority
[20:18] <helix84> mdiggory: you have that in the submission process. the purpose of BME is to automate stuff.
[20:18] <helix84> bollini: like i said, you can do that. you can remove authority that way, too.
[20:18] <tdonohue> Starting to wonder if we're kinda heading off on a large side-discussion. Should we move these brainstorms/questions/suggestions over to the DS-1084 ticket itself?
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1084 ] - [#DS-1084] Handle authority and confidence fields in Bulk Editing - DuraSpace JIRA
[20:19] <mdiggory> helix84: but also the puropse of Reviewer workflow is to address such issues as well, an Ideal Configurable Workflow step might be to address authority mappping recommendations
[20:19] <mdiggory> tdonohue: true
[20:19] <helix84> mdiggory: I think we just have a misunderstanding here. It works the way I think it should.
[20:20] <mdiggory> I'm glad to see it works the way you think it should...
[20:20] <tdonohue> I suggest moving the conversation/questions over to Ds-1084, that way helix84 and keiji can help clarify how it works and make sure there's no implementation concerns
[20:20] <helix84> bollini: if you had a row with authority and overwrite it with a value in CSV without authority (without ::), it will remove the authority information from DB, keeping just the text_value
[20:21] <bollini> helix84: this is not the current behavior. Currently an automatic check will be performed
[20:21] <tdonohue> ok, moving discussion back over to the current 3.0 Submissions list. Are there specific new features we'd like to talk about here today & potentially vote on?
[20:21] <helix84> bollini: a check of what?
[20:22] <helix84> bollini: we can continue in PM if you wish
[20:22] <tdonohue> helix84 & bollini -- I suggest moving your side conversation over to #dspace if you want to continue right now
[20:22] <helix84> ok tim
[20:22] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:23] <tdonohue> asking again: Are there specific new features we'd like to talk about here today & potentially vote on?
[20:23] <bollini> yes
[20:24] <bollini> I need to know what the community think about the discovery porting to JSPUI
[20:24] <bollini> DS-1217 DS-1218
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-1217 ] - [#DS-1217] DSpace Discovery for JSPUI - DuraSpace JIRA
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-1218 ] - [#DS-1218] BrowseDAO based on discovery - DuraSpace JIRA
[20:24] <bollini> pull request exist for both
[20:24] <KevinVdV> I will attempt to review in the comming days bollini !
[20:25] <tdonohue> thanks KevinVdV, we'd definitely appreciate your input/thoughts, since I know you are the Discovery expert ;)
[20:25] <bollini> ok, I suggest to start with DS-1218
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1218 ] - [#DS-1218] BrowseDAO based on discovery - DuraSpace JIRA
[20:26] * sands (~sandsfish@66-189-8-168.dhcp.oxfr.ma.charter.com) has joined #duraspace
[20:27] <bollini> I'm also confident that the solr browse provider will be aware of the access right (you recent improvements) - or it will be easy to update
[20:27] <sands> Hi all, sorry to be late but I've been getting freenode errors for half an hour.
[20:27] <mdiggory> I think the big question is if we really want to have two separate API for querying
[20:27] <bollini> I big question that I have is: should the 3.0 move discovery to be the standard setup for dspace (I think so)
[20:28] <mdiggory> Browse vs Discovery
[20:28] <bollini> mdiggory: agree, I think that in the long run we should rethink about the browse and move to only one api (Discovery)
[20:29] <helix84> sands: [19:34] -christel- [Global Notice] Hi all, normal services (harr, see what I did there?) should return momentarily -- unfortunately one of our major sponsors suffered loss of power and a grue had eaten the UPS! Stuff is starting to return and we shall soon be back in business. Thank you for being patient.
[20:29] <tdonohue> I think my question is similar to mdiggory's -- I notice in pull #67 (https://github.com/DSpace/DSpace/pull/67/files) that the idea is to add new "browseDAO.class" configs to dspace.cfg, which seems slightly odd to me https://github.com/DSpace/DSpace/pull/67/files#L7R859
[20:29] <kompewter> [ Pull Request #67: [READY FOR REVIEW] DS-1218 BrowseDAO based on discovery by abollini · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/67/files)
[20:29] <mdiggory> Our Discovery work seeks to have Brwse capabilities as a subset of its functionality, but we did not want to be tied to the original Browse design
[20:29] <kompewter> [ Pull Request #67: [READY FOR REVIEW] DS-1218 BrowseDAO based on discovery by abollini · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/67/files#L7R859
[20:30] <mdiggory> IF we are going to have DAO, they should be configured in the Spring Context of the ServiceManager
[20:31] <mdiggory> I'll just note we do not have the counter points to this argument because rrodgers is absent today
[20:32] <tdonohue> yea, rrodgers would have good feedback here :)
[20:32] <mdiggory> I guess one other point might be, does the BrowseDAO work provide eventual stepping stones to migrating to a pure discovery based solution?
[20:33] <mdiggory> IE, did we want to back Browse with Discovery, or conversely, do a legacy Discovery that was Browse/DSQuery based, but limited in functionality
[20:34] * mdiggory leans to choose that which we have code for now....
[20:35] <mdiggory> well, the pull request is there, so its in the list, I'd recommend further time for feedback
[20:35] <bollini> the current implementation is a legacy implementation that is limited in functionality
[20:35] <bollini> (ie no number of items in author browse)
[20:35] <tdonohue> I feel like we're drifting into another topic around whether Discovery should replace DB-based browse (or be the default option) -- which to me is a separate decision from whether JSPUI should also use Discovery.
[20:36] <bollini> but, browse is used in other place in dspace other than browsing (item map, withdrawn, recent submission - jspui onlu)
[20:37] <bollini> tdonohue: yes solr browse is separated from the jspui discovery
[20:37] <mdiggory> tdonohue: I agree, but there is one last followup to bollini
[20:37] <mdiggory> in a DDD approach, one might recommend that these queries should be part of the DOmain Model / API
[20:38] <bollini> I like the idea to move dspace to a default setup where we use SOLR for all (search: discovery XMLUI/JSPUI, browse)
[20:39] <tdonohue> However, if we should want to discuss or even vote on whether Discovery should become the "default option" in 3.0, then I'd suggest we may want to bring that up in a more public forum first (e.g. dspace-devel). I'd welcome the discussion, but I think it should be more public than our "smallish" group that we have today
[20:39] <mdiggory> Item.query(QueryPattern q); where QueryPattern might be something like Withdrawn Items, with sort and fitler options
[20:41] * ChanServ (ChanServ@services.) has joined #duraspace
[20:41] <sands> tdonohue: +1
[20:41] <tdonohue> Should we kick off a broader discussion / vote on Discovery becoming the "Default browse/search" for 3.0? I'm willing to help do that if we feel that's a good route to take.
[20:42] <mdiggory> Such Query Patterns would generally reside on the "Repository" object for Item. In our current design, those are the static methods... find(...)
[20:42] <bollini> mdiggory: I think that go ahead of a small step is better than do nothing
[20:42] <mdiggory> tdonohue: I think that should happen in devel....
[20:43] <mdiggory> bollini: I can agree to that...
[20:43] <hpottinger> tdonohue: broader discussion (prolly devel): +1
[20:43] <bollini> mdiggory: yes, I agree with you probably we should rethink about the API in a DDD way, but this is much more complex that fix our current system to use the technology that we have chosen for the future
[20:44] <mdiggory> true, it is out of scope for this dialog / dspace version
[20:44] <helix84> just my point of view here - I didn't put discovery to production when it was introduced in 1.7, only in 1.8. Since Discovery/JSPUI is new, I'd wait with setting it as default after it received some wide exposure and testing. Just my 2c.
[20:45] <mdiggory> there are some further items we'd like to put out here for 3.0 today
[20:45] <bollini> having a SOLR browse DAO will help in several way: 1) better performance, 2) one central point of failure to check/understand (also avoiding conflict result from search and browse), 3) new features (right awareness)
[20:45] <tdonohue> ok, let's move along from Discovery then. Go ahead mdiggory. (I'll start up a Discovery "as default" discussion thread on dspace-devel later this week)
[20:45] <mdiggory> [DS-1194] [DS-1243] [DS-1130]
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-1194 ] - [#DS-1194] Item Level Versioning - DuraSpace JIRA
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-1243 ] - [#DS-1243] @mire solr statistics contribution - DuraSpace JIRA
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-1130 ] - [#DS-1130] Create controlled vocabulary support for the XMLUI. - DuraSpace JIRA
[20:46] <mdiggory> These three have pull requests as well.
[20:46] <tdonohue> do you have pull request links? They aren't in the JIRA tickets
[20:46] <KevinVdV> Only item level seems to be missing
[20:46] <KevinVdV> I'll ad it asap
[20:46] <mdiggory> https://github.com/DSpace/DSpace/pull/72
[20:46] <kompewter> [ Pull Request #72: [DS-1194] Atmire dspace 3.0 versioning contribution by KevinVdV · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/72
[20:46] <tdonohue> Oh, here's item level: https://github.com/DSpace/DSpace/pull/72
[20:47] <kompewter> [ Pull Request #72: [DS-1194] Atmire dspace 3.0 versioning contribution by KevinVdV · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/72
[20:47] <mdiggory> https://github.com/DSpace/DSpace/pull/69
[20:47] <kompewter> [ Pull Request #69: [DS-1243] @mire solr statistics contribution by KevinVdV · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/69
[20:47] <mdiggory> https://github.com/DSpace/DSpace/pull/71
[20:47] <kompewter> [ Pull Request #71: [DS-1130] Controlled vocabulary support for the XMLUI by KevinVdV · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/71
[20:47] <KevinVdV> Allright they should all have pull requests attached !
[20:48] <tdonohue> Ok, since we need to start somewhere...let's start at DS-1194 feedback
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-1194 ] - [#DS-1194] Item Level Versioning - DuraSpace JIRA
[20:49] * tdonohue realizes we cannot do too big of a deep review here. But, if we can locate a few volunteers to look more deeply in coming days, that'd be good
[20:49] <mdiggory> Item LEvel Versioning support introduces the ability to version the Item/Bundle/Bitstream aggregates
[20:49] <bollini> I'm sorry, I'm having trouble with my internet connection so I was missed your previous comments (checking now the irclogs)
[20:49] <helix84> mdiggory: i understand it creates a new item for each version, right?
[20:49] <tdonohue> mdiggory -- is Item Level Versioning compatible with AIP Backup & Restore? (just wondering if there's work to be done there in coming weeks)
[20:49] <mdiggory> New Versions are completely new Items with BitstreamStorageManager contents conserved across Bitstream object versions.
[20:50] <mdiggory> tdonohue: there is testing work that will need to be done.
[20:50] <tdonohue> ok.
[20:51] <mdiggory> one should be able to backup and restore separate versions, however, it may be the case that, unless internal bitstream ids are preserved in the AIP, the BitstreamStorageManager may not be able to reintroduce the same level of conservation.
[20:52] <tdonohue> internal ids are not guarranteed preserved by AIPs. Just the "external" IDs (handles) are preserved/restored.
[20:52] <mdiggory> we will also need to confirm that the version history is restored and/or preserved in some manner, there may still be some small work on that
[20:52] <tdonohue> yep. would require some further analysis for sure
[20:52] <mdiggory> tdonohue: I'm critical about the treatment of internal ID's in Bitstreams
[20:53] <tdonohue> (note: this doesn't make me against this feature though -- personally, I'd *love* to see some versioning in DSpace. Just need more time to review this)
[20:53] -mquin- [Global Notice] Services are back now but may be a little slow while everthing settles down. Thank you for your patience, and for flying freenode!
[20:53] <sands> mdiggory, how is history persisted?
[20:53] <mdiggory> I'm not convinced that this data should be hidden and that its important that it be preserved so that a BitstreamStorageManager could reconstitute an identical result on restoration.
[20:54] <mdiggory> version history is persisted in its own table at this time.
[20:54] <mdiggory> this was intended to assure that there is data integrity across all of the versioning system
[20:55] <mdiggory> if it were stored in the metadata, edits to the metadata could break the version history
[20:55] <helix84> https://github.com/DSpace/DSpace/pull/72/files#L43R792
[20:55] <kompewter> [ Pull Request #72: [DS-1194] Atmire dspace 3.0 versioning contribution by KevinVdV · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/72/files#L43R792
[20:55] <mdiggory> and likewise, they "alter" the previous item in the process of creating the new item, which isn't ideal
[20:56] <mdiggory> Yes helix84, that shouldn't be there
[20:56] <tdonohue> makes sense. I'm assuming that each Item Version is not duplicating unchanged objects (e.g. an unchanged Bitstream may be linked to from multiple Item versions)?
[20:56] <helix84> mdiggory: how so?
[20:56] <mdiggory> wait, helix84 are you referring th=o the pom change?
[20:57] <tdonohue> helix84 is linking to the versionhistory table definition
[20:57] <helix84> no, just pinting sands to the table definition
[20:57] <helix84> s/pinting/pointing/
[20:57] <kompewter> helix84 meant to say: no, just pointing sands to the table definition
[20:57] <mdiggory> oh, I'm getting the whole diff
[20:57] <tdonohue> but, I did notice odd dspace-api/pom.xml changes that may have crept into this pull request accidentally
[20:57] <sands> helix thanks. mdiggory, that makes sense. was there any thinking already done about how to persist that (history) across repositories? like a codec type situation where it is reconstituted if the destination is a 3.0+ DSpace repo? just curious. don't think it's a requirement.
[20:58] <mdiggory> yes, the next merge will correct that
[20:58] <KevinVdV> Tdonohue: those changes are needed
[20:58] <KevinVdV> We wrote unit tests for the versioning & because of this we needed a running DSpace kernel in the unit tests
[20:58] <KevinVdV> Hence we needed to move the dspace.cfg file in the dspace dir used for testing
[20:59] <tdonohue> So, I hate to ask, but how does this Item Versioning affect all other iterfaces? I notice most of the code is XMLUI. What happens in the JSPUI / OAI / SWORD? Or will that require further testing?
[21:00] <tdonohue> s/iterfaces/interfaces/
[21:00] <kompewter> tdonohue meant to say: So, I hate to ask, but how does this Item Versioning affect all other interfaces? I notice most of the code is XMLUI. What happens in the JSPUI / OAI / SWORD? Or will that require further testing?
[21:04] <mdiggory> sorry, internal dialog..... I'm back
[21:05] <mdiggory> tdonohue: the objective of versioing is currently that it is a manual process initiated by the UI user
[21:05] * tdonohue notes we're obviously heading into "overtime" here. If you have to head out, feel free. I'm gonna stick around here a bit longer though to better understand this work. I'd also suggest that folks start to help us review Pull Requests (https://github.com/DSpace/DSpace/pulls), esp. those that may be of interest to your or your institution.
[21:06] <mdiggory> The current functionality uses the XMLUI, Items should still be viewable in JSPUI and other interfaces, however, at the moment these interfaces cannot spawn new versions of items
[21:06] <bollini> I can check the JSPUI side and make the necessary addition for support versioning in jspui starting from September if needed
[21:06] <mdiggory> bollini: that would be beneficial
[21:06] <sands> +1 to everyone reviewing pull requests. The RT will do its best but we want everyone's eyes and feedback on these contributions to the extent that people have time.
[21:07] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Remote host closed the connection)
[21:07] <mdiggory> I'd like to quickly move to https://github.com/DSpace/DSpace/pull/69
[21:07] <kompewter> [ Pull Request #69: [DS-1243] @mire solr statistics contribution by KevinVdV · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/69
[21:07] <tdonohue> sands -- i'd highly recommend sending a note to dspace-commit even to ask for help too
[21:07] <sands> tdonohue: i'll definitely do that.
[21:07] <bollini> I want to suggest to be flexible with the deadline especially in case like this where new code could be needed to restore parity between interfaces
[21:07] <mdiggory> we have a concern in relation to PeterDietz work on elasticsearch based stats
[21:07] <sands> mdiggory: i read your critiques earlier today. thanks for all of the excellent analysis work there.
[21:08] <mdiggory> thank KevinVdV
[21:08] <KevinVdV> No problem
[21:08] <sands> KevinVdV thanks!
[21:08] <mdiggory> https://github.com/DSpace/DSpace/pull/63
[21:08] <kompewter> [ Pull Request #63: DS-1241 Statistics implementation in Elastic Search by peterdietz · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/63
[21:09] <PeterDietz> Much of this are quick and easy fixes, that probably should have been done the way mentioned by kevin/mark in the first place, but I appreciate the feedback in catching them
[21:09] <mdiggory> Our concern is that we want make sure that any conflicts are resolved between the two solutions so that new features we bring into stats fit well with those in PeterDietz work
[21:10] <PeterDietz> Thats another of the points. There is common interaction between both pieces (solr / es), so Solr needs to go in first, then I'll update ES to accomodate those changes.
[21:10] <mdiggory> I want to revert my comments last week that we should attempt to integrate each solution behind a single statistics API
[21:11] <mdiggory> I think, similar to the BrowseDAO work, we should start with separate solutions in 3.0 and see if we find some parity for a future release
[21:13] <mdiggory> I think the important concern is... in a bullet point about halfwaydown the comment
[21:13] <mdiggory> We noticed a lot of code has been added to the solr StatisticsTransformer that isn't used (perhaps some left overs ? We recommend shifting changes out of Statistics Transformer and possibly creating a separate aspect for the time being).
[21:14] <mdiggory> Each solution should probably be a completely separate aspect with separate code, including transformers
[21:15] <PeterDietz> The un-used code is from this being cloned from OSU's repo, we have a snazy dashboard, that I haven't contributed to DSpace. I'll trim it out
[21:16] <tdonohue> I just want to note here, that I'm slightly worried about how to explain the differences between the Solr Statistics and the Elastic Search Statistic, which one to use in which scenario and how to switch between them (if that's even possible). This seems like it could require a lot of 3.0 Documentation
[21:16] <KevinVdV> Great Peter Dietz !
[21:16] <tdonohue> (Note: I'm not saying it's not possible...just noting that I think it has the potential to be a big confusion point amongst users)
[21:17] <helix84> a really noob question from me to PeterDietz: does ES require installing some external software? (like Discovery requires Solr) Or will it be a part of the DSpace distribution already?
[21:17] <mdiggory> So I think the final request is can we accept 69 before 63?
[21:17] <PeterDietz> I'm nervous about forcing all stats-data to go into unified stats. For 3.0 we'll get both solutions working independently, For 3.1, we can refactor these to use a common data object / common display UI
[21:17] <tdonohue> PeterDietz : 3.1 is bug fixes only. No api changes would be allowed unless they are a bug fix
[21:17] <tdonohue> You'd have to wait for 4.0 to do major refactoring
[21:18] <PeterDietz> I did a bit of an overhaul to the code to make it so no additional services will need to be running. I.e. elasticsearch has a node that lives inside of DSpace's tomcat JVM
[21:18] <PeterDietz> 3.0.0 vs 3.0.1 vs 3.1.0
[21:18] <mdiggory> We'd probibly need that much time anyhow....
[21:18] <PeterDietz> Perhaps I'm not following proper number scheme
[21:18] <helix84> PeterDietz: how much memory does it eat (order of MB)?
[21:18] <mdiggory> 3.0, 3.1 , 3.2, 4.0, 4.1 , 4.2
[21:18] <tdonohue> PeterDietz: there's no such thing as "3.0.1" anymore. The new numbering scheme is 3.0, 3.1 (bug fix only), 3.2 (bug fix only), 4.0
[21:19] <PeterDietz> 142.28 Petabytes
[21:19] <helix84> umm, how much JVM memory...
[21:19] <mdiggory> 142.28 Dinobiscuits
[21:19] <helix84> :p
[21:20] <hpottinger> mdiggory's probably right, in order to get the refactoring right, 4.0 (one year out) is what it would take, thus I predict :-)
[21:20] <mdiggory> hpottinger as spoken, and thus it is so
[21:21] <PeterDietz> I have it in the code, but need to add it to the configs, but you can easily change your ES architecture, to make DSpace use a seperate server for Elastic Search
[21:21] <mdiggory> Does this introduce ES as a default dependency in the build?
[21:22] <mdiggory> we need to think about this in relation to the maven project consolidation
[21:22] <PeterDietz> Its options are LocalClient (runs everything inside tomcat's JVM), NodeClient (lives in tomcat's JVM, but can talk to neighbor nodes), TransportClient (talks over IP to another server for all ES traffic)
[21:22] <mdiggory> if most of dspace-stats gets rolled into dspace-api
[21:23] <mdiggory> and/or we do stats-solr and stats-es
[21:24] <PeterDietz> I do realize that I didn't know how to have applicationContext.xml conditionally fire events to Elastic Search if its enabled or not.
[21:24] <mdiggory> which reminds me that MPC is probably a special request to be put up after the PR deadline this friday
[21:25] <mdiggory> PeterDietz: I think we need to fix th use of those separate spring application context definitions
[21:25] <tdonohue> MPC? PR? mdiggory is now talking in code
[21:25] <mdiggory> blip zurp ding
[21:25] <PeterDietz> I don't know MPC, Mark's PC?
[21:25] <tdonohue> oh, guessing PR = "Pull Request"
[21:26] <mdiggory> Maven Project Consolidation
[21:26] <mdiggory> chaching
[21:26] <mdiggory> PeterDietz: are you referring to....
[21:26] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/WEB-INF/spring/applicationContext.xml
[21:26] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/WEB-INF/spring/applicationContext.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/WEB-INF/spring/applicationContext.xml
[21:27] <bollini> sorry, need to go... I will read the transcription tomorrow. Good Night
[21:27] <tdonohue> mdiggory -- yes, the maven project consolidation should be put forward as a special request (even before friday, if you get the chance). I think most folks seemed in favor, but we just need to give a final stamp & make sure we get it scheduled.
[21:27] <PeterDietz> yep, that one.
[21:27] <mdiggory> tdonohue: ok
[21:27] <PeterDietz> <!-- Inject the Default LoggerUsageEventListener into the EventService -->
[21:27] <PeterDietz> <bean class="org.dspace.statistics.SolrLoggerUsageEventListener">
[21:27] <PeterDietz> <property name="eventService" >
[21:27] <PeterDietz> <ref bean="dspace.eventService"/>
[21:27] <PeterDietz> </property>
[21:27] <PeterDietz> </bean>
[21:27] <mdiggory> PeterDietz: yea, this should be gotten rid of....
[21:27] <PeterDietz> <!-- Elastic Search -->
[21:27] <PeterDietz> <bean class="org.dspace.statistics.ElasticSearchLoggerEventListener">
[21:27] <PeterDietz> <property name="eventService">
[21:27] <PeterDietz> <ref bean="dspace.eventService" />
[21:27] <sands> I've unfortunately got to bow out as well. Talk to you all off channel. Cheers.
[21:27] <PeterDietz> </property>
[21:27] <PeterDietz> </bean>
[21:27] * sands (~sandsfish@66-189-8-168.dhcp.oxfr.ma.charter.com) Quit (Quit: sands)
[21:28] * bollini (~chatzilla@host216-210-dynamic.37-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
[21:28] <PeterDietz> (my PR makes ES come in)
[21:28] <mdiggory> the loggers should instead be configured in...
[21:28] <hpottinger> re the MPC timing, I think the timing was discussed during OR12 dev mtg, yes?
[21:28] <mdiggory> https://github.com/DSpace/DSpace/tree/master/dspace/config/spring
[21:28] <kompewter> [ DSpace/dspace/config/spring at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/tree/master/dspace/config/spring
[21:29] <tdonohue> hpottinger: may have been -- I wasn't there :) If something was decided then, that's fine. Just be good to make sure we all know what that something was :)
[21:29] <mdiggory> then you can enable/disable the loggers in the config directly, not have to override the files in the webapp overlay
[21:29] <mdiggory> this is just old design that needs to get tossed
[21:30] <hpottinger> https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[21:30] <kompewter> [ DevMtg 2012-07-09 - OR12 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[21:30] <tdonohue> Is there anything left needing feedback from all of us? Noticing this is turning into mdiggory & PeterDietz discuss details (which is fine). Just want to make sure we take advantage of folks who are still here if we need to.
[21:30] <KevinVdV> Well if we still have time: https://jira.duraspace.org/browse/DS-1130
[21:30] <kompewter> [ [#DS-1130] Create controlled vocabulary support for the XMLUI. - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1130
[21:30] <hpottinger> "Mark Diggory would like to do some Maven restructuring/refactoring, which makes the most sense to do as part of the RC release process, post-feature-freeze, so as to minimize the impact on active development."
[21:30] <kompewter> [ https://jira.duraspace.org/browse/DS-1130 ] - [#DS-1130] Create controlled vocabulary support for the XMLUI. - DuraSpace JIRA
[21:30] <KevinVdV> A smaller contribution
[21:32] <tdonohue> hpottinger: I think my question here was what does "post-feature-freeze" mean? Do we want to set a more specific deadline to ensure we have time to do a bit of basic tests before 3.0RC1? Also, I notice that statement says "Mark Diggory would *like* to do...", which I wasn't sure if that implied it gathered widespread approval yet or not?
[21:33] <tdonohue> (To be clear though, I'm +1 this maven project consolidation. I just wasn't sure if it still needed an official vote or not?)
[21:33] <PeterDietz> I thought we already discussed MPC and it got more or less aproved
[21:33] <mdiggory> I do like that Controlled Vocabulary becomes an API object...
[21:34] <mdiggory> suggests it may be eventually integrated with the DSpace data model more formally
[21:35] <tdonohue> ok, maybe I'm remembering wrong. I do remember discussing it, I just didn't really recall a vote on MPC.
[21:35] <mdiggory> tdonohue: PeterDietz: yes but at the time we didn't have two different deadlines for features and final work.
[21:35] <tdonohue> yep, that's true
[21:36] <tdonohue> I think my main point here is that we (all committers) need to know when MPC is going to *happen* (i.e. actual work is going on), so we aren't doing something else (e.g. bug fixes, etc) at the same time. MPC is a huge change and it needs planning/scheduling
[21:36] <hpottinger> I'm about halfway through a note to dspace-release asking for clarification of timing on MPC work, figured I'd say something before I hit send
[21:37] <mdiggory> well, theres a pull request in existence, if the work continues on it, we should be considered in by friday...
[21:37] <mdiggory> its just broken due to staleness...
[21:38] <tdonohue> mdiggory -- right. I think you misunderstand. I agree that MPC can be considered for 3.0. I just want us to careful plan out the date that someone *merges* that work in Master, as that date has the potential to affect everyone who is doing anything else in Master
[21:38] <mdiggory> just consider it last on the list of PR to be commited by the final date
[21:39] <tdonohue> i.e. the date that MPC gets merged into Master is the date that all other "open" pull requests will become "stale"
[21:40] <mdiggory> its pretty much that case with most PR already... its only if completely separate files were touched that the PR seem to stay automajically mergable
[21:41] <tdonohue> right, I agree. just noting that MPC has the potential to touch nearly every file in the codebase (i.e. a lot gets moved around). So, we need to warn the Committers in advance. It'd be nice to say something like..."Warning MPC will be merged on Sept 14. Make sure you are prepared!"
[21:42] <mdiggory> One last topic... do we want to start using the milestone classification on the pull requests? we could have a couple mielstones for the PR and classify / order them
[21:42] <hpottinger> tdonohue +1
[21:43] <PeterDietz> its getting to be lots of things, with potentially different deadlines. i.e 3.0, and then if anything gets bumped to post-3.0
[21:43] <tdonohue> mdiggory: I'm fine with using "milestones" to correspond to DSpace versions. I know there are likely some PRs that will get bumped to "4.0"
[21:44] <mdiggory> I just don't know yet where to make one
[21:45] <tdonohue> Oh, actually we may not be able to use github "milestones" as we don't use the Release Tracking feature of GitHub ?
[21:45] <hpottinger> OK, I gotta go, will send this note to dspace_release and check in later.
[21:45] <tdonohue> s/Release Tracking/Issue Tracking/
[21:45] <kompewter> tdonohue meant to say: Oh, actually we may not be able to use github "milestones" as we don't use the Issue Tracking feature of GitHub ?
[21:46] <helix84> jira already have milestones
[21:46] <tdonohue> helix84 -- yea, I agree. I think the reason folks wanted the milestones in GitHub was just to avoid having a giant "bucket" of pull requests
[21:47] <mdiggory> Ok, sounds like we need to "hack" for now
[21:47] <helix84> there's a lot of duplicate functionality and we're already facing the "jira or github" problems already (e.g. with comments)
[21:47] <mdiggory> Maybe we just put in PR description or title
[21:47] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:48] <mdiggory> yes, helix84 I agree
[21:48] <helix84> on a related note, could we have {RFR] instead of [REQUEST FOR REVIEW] and [DONE] instead of [COMPLETED]?
[21:48] <helix84> just keeping the PR titles shoty
[21:48] <helix84> short
[21:48] <tdonohue> We could just use the "mdiggory hack way" and prefix PR's with "[RESCHEDULED]" as needed.
[21:49] <KevinVdV> Needs to run ! Until next week
[21:49] <tdonohue> I personally don't like the "[COMPLETED]" or "[DONE]" labels...I think they should be replaced by "[RFR]", as no pull request is ever *done* until it's been reviewed & merged
[21:49] <mdiggory> sounds good...
[21:49] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.)
[21:49] <helix84> right, i didn't like it either
[21:49] <mdiggory> KevinVdV: tdonohue the CV work seems small, do we need a vote on it?
[21:49] <helix84> what does that leave us with?
[21:51] <tdonohue> Controlled Vocab work is just a port of existing functionality to XMLUI, in which cause I'm assuming it wouldn't need a vote unless there's anything that really could be controversial in it
[21:51] <mdiggory> tdonohue: I agree... those labels would be removed before accepting anyhow
[21:51] <tdonohue> I unfortunately have to run...will need to catch up later
[21:51] <mdiggory> introduction of gson... but that seems a beneficial feature for the recommendations to PeterDietz work as well...
[21:52] <tdonohue> With the CV work, if one other committer takes a glance at it, then I think it'd be OK to put in.
[21:52] <mdiggory> ok
[21:52] <tdonohue> (i.e. everything should get a few sets of eyes, but not everything needs a formal vote)
[21:52] <tdonohue> ok. gotta go. bye
[21:52] <mdiggory> bye
[21:52] <kompewter> bye!
[21:53] <PeterDietz> I'm happy with GSON, I'm already using it in ES somewhere
[21:53] <mdiggory> kompewter: you never get to leave....
[21:53] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:53] <mdiggory> PeterDietz: cool...
[21:53] <mdiggory> can you look over CV?
[21:54] <PeterDietz> That looks like PR#71
[21:55] <mdiggory> yes
[21:56] <PeterDietz> yep, I can check it out. Also, thank you (and probably mostly Kevin) for the analysis of ES stats. There's lots of goodies to fix.
[21:57] <PeterDietz> I'm out. Its stop-being-at-work time.
[21:57] <mdiggory> Yes, theres some good stuff there already, and a some point... ES based Discovery will also be quite interesting....
[21:57] <PeterDietz> P.S. Completely unrelated to anything, but Pres Obama was in Columbus yesterday, and the entourage completely shutdown everything for a moment
[21:57] <PeterDietz> It was a suprise visit too
[21:58] <mdiggory> Did you try to see him?
[21:58] <mdiggory> Anyhow... back to work on this end....
[21:59] <PeterDietz> I was able to see the back of his head as his limo passed. He went to some first-week-of-school-assembly.
[21:59] <PeterDietz> My wife (currently pregnant), said if he comes back to town, and we're stuck in the car during labor, and we're forced to birth in the car, then she's voting for Romney.
[22:00] <PeterDietz> ok, out.
[23:34] * helix84 (a@195.113.97.174) Quit (Quit: helix84)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.