Timestamps are in GMT/BST.
[6:46] -wolfe.freenode.net- *** Looking up your hostname...
[6:46] -wolfe.freenode.net- *** Checking Ident
[6:46] -wolfe.freenode.net- *** Found your hostname
[6:46] -wolfe.freenode.net- *** No Ident response
[6:46] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:46] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:46] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:31] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:58] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[16:00] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[16:40] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) has joined #duraspace
[18:45] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) has joined #duraspace
[19:31] * KevinVdV (~KevinVdV@d5153d041.access.telenet.be) has joined #duraspace
[20:00] * mhwood (~mhwood@adsl-99-1-96-171.dsl.ipltin.sbcglobal.net) has joined #duraspace
[20:01] <tdonohue> Hi all, welcome. It's time for the weekly DSpace Developers Meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-05-13
[20:01] <kompewter> [ DevMtg 2015-05-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-05-13
[20:02] <tdonohue> The primary topic for today is obviously the 5.2 bug fix release, and where things stand for that (especially since we had tentatively scheduled it for tomorrow)
[20:02] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.2+Status
[20:02] <kompewter> [ DSpace Release 5.2 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.2+Status
[20:03] <hpottinger> either I or aschweer will write the docs for DS-2486, thanks to tdonohue's advice on where to put them
[20:03] <tdonohue> So, the question is, how do we look? It looks like we have the biggest bug in (DS-2486).
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2486 ] - [DS-2486] Missing fields in solr statistics data from previous DSpace versions - DuraSpace JIRA
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2486 ] - [DS-2486] Missing fields in solr statistics data from previous DSpace versions - DuraSpace JIRA
[20:04] <tdonohue> We do seem to have a fair number of open PRs still "tentatively scheduled" for 5.2 though https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[20:04] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[20:04] <tdonohue> Are we leaving the rest of those PRs behind? Any last ones to work in here?
[20:04] <peterdietz> helix84: Mentioned he and CTU were looking at a REST PR
[20:05] <mhwood> Quite a number of those in Code Review Needed
[20:05] <hpottinger> standard rules still apply, if you have the ability to merge a bug fix, and it's "small", we trust you, go for it
[20:05] <mhwood> Probably too late for Receiveds and Needs Volunteers?
[20:06] <hpottinger> DSPR#893 would be great to get in with the other Solr stats fixes
[20:06] <kompewter> [ https://github.com/DSpace/DSpace/pull/893 ] - [DS-2212] Ignore _version_ field when sharding solr statistics by aschweer
[20:07] <hpottinger> The two people who noticed the sharding bug have tested 893
[20:08] <hpottinger> is that good enough?
[20:08] <hpottinger> it's a one-liner
[20:08] <tdonohue> hpottinger: that looks like a one-liner. If it's been tested by others & looks good to you, I'd say merge it
[20:08] <mhwood> I think sharding is rare. That may *have to* be enough.
[20:09] <hpottinger> it's a cron job we suggest
[20:09] <hpottinger> in the docs
[20:09] <tdonohue> yep, sharding is recommended to run on a yearly basis
[20:09] <tdonohue> (just to keep your index size "smallish")
[20:10] <hpottinger> I don't :-) but I was aware of the bug
[20:10] <mhwood> Time for me to reread the docs as if doing a first install. :-(
[20:11] * aschweer (~andrea@89.75.69.111.dynamic.snap.net.nz) has joined #duraspace
[20:11] <hpottinger> merging 893 now
[20:11] <hpottinger> hey, aschweer, wer'e merging your code
[20:11] <aschweer> excellent :) sorry I'm late, it's early morning here
[20:12] <tdonohue> Another possible 5.2 ticket (which I just encountered): DS-2542 (unfortunately though, the full fix seems to be waiting on XOAI / Joao)
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-2542 ] - [DS-2542] XOAI does not support non granular YYYY-MM-DD harvesting properly - DuraSpace JIRA
[20:14] * tdonohue really wishes we had control over XOAI
[20:15] <hpottinger> OK, 893 has been backported to 5_x branch
[20:16] <hpottinger> aschweer: if you want to do the honors, DS-2212 is closable
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-2212 ] - [DS-2212] Statistics Shard not working, version conflict - DuraSpace JIRA
[20:18] <aschweer> does it still need backporting to dspace-5_x?
[20:18] <hpottinger> I just did
[20:18] <tdonohue> Hmmm.. not to sidetrack this, but I just realized XOAI seems to have been inactive since last summer? https://github.com/lyncode/xoai/ Wonder if we are gonna need to "fork" it for ourselves eventually to get things like 2542 fixed
[20:18] <kompewter> [ lyncode/xoai · GitHub ] - https://github.com/lyncode/xoai/
[20:18] <mhwood> It looks like 2542 has two workarounds that add up to "fixed enough for now."
[20:19] <tdonohue> 2542 doesn't actually have a workaround other than pulling an unreleased version of XOAI
[20:20] <tdonohue> Or always specifying dates with a full timestamp (which isn't part of the OAI-PMH spec)
[20:21] <hpottinger> tdonohue: do you want to propose we fork xoai?
[20:21] <tdonohue> In any case, it sounds like it's not "ready" quite yet (without a new XOAI), so we can get on to other tickets. 2542 is just an annoyingly small bug that I wish we could just fix without relying on XOAI
[20:21] <tdonohue> yes, I'm starting to suspect we should. Maybe I'll suggest that on -commit?
[20:22] <hpottinger> tdonohue: good plan, discussion will likely ensue
[20:22] <mhwood> I'm not opposed.
[20:22] <tdonohue> Any other 5.2 tickets / PRs we want to touch on? Here's that PR list again: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[20:22] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.2
[20:23] <hpottinger> mhwood: DSPR#942 is definitely in "we trust you" territory, do you need a sanity check?
[20:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/942 ] - [DS-2379] command usage output for dspace (from launcher.xml) is unsorted by mwoodiupui
[20:24] <tdonohue> DSPR#939 also looks "really tiny" aschweer, and seems like a "we trust you"
[20:24] <kompewter> [ https://github.com/DSpace/DSpace/pull/939 ] - DS-2449 mirage2 template label by aschweer
[20:24] <aschweer> it is really tiny
[20:24] <mhwood> I'll go ahead and pull 942. I did test it.
[20:25] <tdonohue> aschweer: merge it then, if it works for you
[20:25] <tdonohue> please ;)
[20:25] <aschweer> DS-2544 would be great to get in (DSPR#917), it can be annoying since it will probably generate a lot of thumbnails on the first run after upgrading to DSpace 5
[20:25] <kompewter> [ https://github.com/DSpace/DSpace/pull/917 ] - [DS-2544] Improve temp file handling for IM thumbnailer by aschweer
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-2544 ] - [DS-2544] Disk space creeps up when media-filter creating thumbnails using ImageMagickThumbnailFilter - DuraSpace JIRA
[20:25] <tdonohue> 917 should be merged. I reviewed the code. It's verified to work by another user
[20:25] <hpottinger> yay, more green buttons!
[20:26] <tdonohue> (the only reason I haven't merged 917 myself is that I haven't had time recently to even spin up my dev environment)
[20:26] <peterdietz> What does this mean: //noinspection ResultOfMethodCallIgnored
[20:26] <tdonohue> anyone willing to do the honors?
[20:27] <tdonohue> peterdietz: where are you seeing that?
[20:27] <aschweer> sorry, it's an IntelliJ thing, it just tells the code inspection tool not to complain about ignoring the boolean return value
[20:27] <peterdietz> https://github.com/DSpace/DSpace/pull/917/files#diff-18685d20ba61a8c48e855fbfb72142caR43
[20:27] <kompewter> [ [DS-2544] Improve temp file handling for IM thumbnailer by aschweer · Pull Request #917 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/917/files#diff-18685d20ba61a8c48e855fbfb72142caR43
[20:27] <tdonohue> oh, I see
[20:28] <peterdietz> I guess I could pay more attention to intellij. Its a really good editor. I'm just so blinded by seeing so much red and yellow, that I only pay attention to the severe ones, and the compiler
[20:29] <tdonohue> so, do we have volunteers to merge 917, 939, and 942? Sounds like we have approved all three
[20:29] <mhwood> 942 is in master, now I need to cherrypick it to 5_x
[20:29] <aschweer> same for 939
[20:30] <aschweer> I just realised I may not be set up for committing to github from here (home)
[20:30] <hpottinger> have a machine that can run vbox?
[20:31] <tdonohue> Oh, hmm... this one is a "blocker" DS-2545 / DSPR#938 - we kinda need to fix this in 5.2
[20:31] <kompewter> [ https://github.com/DSpace/DSpace/pull/938 ] - DS-2545: Show collections the user can submit items to only. by pnbecker
[20:31] <kompewter> [ https://jira.duraspace.org/browse/DS-2545 ] - [DS-2545] JSPUI offers collections in the submission process the user is not allowed to commit to - DuraSpace JIRA
[20:32] <hpottinger> JSPUI
[20:33] <tdonohue> right, it is JSPUI. But, it does sound like something that could be considered a "blocker" / must fix
[20:33] <tdonohue> I wish pbecker was here today, as it seems like it's also something that could be a "if it works for you, please merge it"
[20:33] <hpottinger> any other JSPUI users here?
[20:34] <tdonohue> no likely candidates (in scanning the names in this room)
[20:34] <aschweer> a JSPUI user would be good for DSPR#928 too (though to be honest, that one almost looks straightforward enough to just merge to me)
[20:34] <kompewter> [ https://github.com/DSpace/DSpace/pull/928 ] - DS-2551: JSPUI show thumbnails only if user has read permission by pnbecker
[20:34] <tdonohue> +1
[20:36] <aschweer> anyone have opinions on DSPR#922? it's just a small change to the XSL for oai
[20:36] <hpottinger> tdonohue: are you +1 enough to "just merge it" yourself? :-)
[20:36] <kompewter> [ https://github.com/DSpace/DSpace/pull/922 ] - [DS-2549] Render Repo identifier / Sample identifier on Identify page by aschweer
[20:36] <tdonohue> Both of these look reasonable to me, honestly. If no one wants to take the heat, maybe I'll just fire up my dev environment and merge them
[20:37] <tdonohue> 922 looks like another "just merge it" if it works for you, aschweer.
[20:37] <tdonohue> Honestly any changes that are that small in nature are probably in the "just merge it" category. Or minimally say you'll leave it open for a few days for comment (if any) and then merge it
[20:37] <aschweer> 922 is live on at least one of my production repos, I'll go for it
[20:37] <tdonohue> thanks!
[20:38] <aschweer> ok, I'll stop being so cautious for small tweaks :)
[20:38] <hpottinger> Yay!
[20:38] <tdonohue> What about DSPR#907? Looks like robint is running it in production which seems like a good sign too
[20:38] <kompewter> [ https://github.com/DSpace/DSpace/pull/907 ] - [DS-2534] Fix a bug in the "Jump to" browse feature by kutsurak
[20:39] <hpottinger> +1, I like the way you think, tdonohue.
[20:39] <tdonohue> honestly, if someone is running it in production & it "works", then it's very likely safe
[20:39] <hpottinger> I'll merge 907
[20:39] <tdonohue> thanks, hpottinger
[20:41] <tdonohue> Ok, that just cut down our list of 5.2 PRs pretty well. I'll go ahead and look at those two JSPUI ones (likely not gonna get to it until tomorrow morning though)
[20:41] <tdonohue> Any others to discuss here?
[20:43] <tdonohue> Ok, so should we discuss the 5.2 timeline then? It sounds like we have a bunch of PRs about to be merged. When do we feel comfortable doing the 5.2 release?
[20:43] <hpottinger> I will try my luck with those JSPUI fixes, if I can get the time, I'm doing "real work" in our staging repository, which frees up my dev space for DSpace testing
[20:45] <tdonohue> timelines? hpottinger, I think you had originally volunteered for a 5.2 tomorrow. But, it sounds like we likely need longer. What sounds reasonable to all (and hpottinger are you still doing the releasing)?
[20:46] <hpottinger> I can pull the lever, I'm guessing we'd feel better bumping back to early next week?
[20:47] <hpottinger> Tuesday May 19?
[20:47] <tdonohue> Tues seems good to me. Anytime next week is good by me
[20:50] <tdonohue> Ok, so is that our date? Tues, May 19 is the 5.2 release. That would imply we need these mergers done ASAP, ideally by end of day tomorrow if possible
[20:51] <hpottinger> aschweer: tdonohue made some suggestions on DS-2486 as to where to put the docs
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-2486 ] - [DS-2486] Missing fields in solr statistics data from previous DSpace versions - DuraSpace JIRA
[20:52] <aschweer> hpottinger yup I saw that, thanks tdonohue, I'll see if I can find time in the next few days to sort that out
[20:52] <tdonohue> OK, sounds like we have a general plan for 5.1. So, in the essence of time, I did want to mention another brief update on the "Strategic Planning" / Technical Roadmap work.
[20:52] <hpottinger> I agree, tdonohue, code freeze for 5.2 is tomorrow
[20:52] <tdonohue> 5.2
[20:52] <aschweer> if someone else gets to the 2486 docs first, go right ahead.
[20:52] <hpottinger> 2486 docs: I can copy/paste, get your red pen ready
[20:53] <hpottinger> what time zone is "end of day tomorrow" ?
[20:53] <tdonohue> So, regarding the Strategic Planning work, we've begun drafting (very roughly) a proposed Technical Roadmap at: https://wiki.duraspace.org/display/DSPACE/RoadMap You are welcome to review it & give feedback, but it is also very actively changing (and should start to stabilize over the next week or so)
[20:53] <kompewter> [ RoadMap - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/RoadMap
[20:54] <tdonohue> "end of day tomorrow" basically just means about 24 hours from now, ideally
[20:55] <tdonohue> ~23:59 UTC on Thurs, May 14 (which is probably more like mid-day tomorrow for aschweer)
[20:55] <hpottinger> OK, so 20UTC code freeze
[20:56] <hpottinger> Oh, see, I misunderstood :-)
[20:57] <tdonohue> I don't think we have to set an exact time for a "freeze", but just say that we really want everything in within about 24 hours. If some stuff is a few hours late, it's not the end of the world. But, we don't want things coming in during the weekend or Monday
[20:58] <hpottinger> OK, sorry to derail the road map discussion
[20:59] <hpottinger> so, it looks like 6.0 is the last "bring us what you have" release, and 7.0 will be the first "this is what we want the community to work on" release
[20:59] <tdonohue> There's not a ton to discuss Roadmap wise. I mostly just wanted to let you know "work is going on" at https://wiki.duraspace.org/display/DSPACE/RoadMap It is mostly *my ideas* thus far, and is yet to be fully reviewed by the RoadMap Working Group (or any of you for that matter), so it is almost guaranteed to change. Plus, much more details on individual "candidate features" will be coming
[20:59] <kompewter> [ RoadMap - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/RoadMap
[21:00] <tdonohue> hpottinger: that is correct. 6.0 will be "bring us what you have". 7.0 will be "this is what we need to achieve as a community" (but we also may welcome "bring us what you have" if it matches an important use case)
[21:01] <tdonohue> So, 7.0 will be our first "use case" driven release, in which we'd want to have more organized development (primarily around a single UI)
[21:01] <peterdietz> I think you'll always have a bit of bring what you have. But perhaps prioritizing / petitioning / begging for a certain feature set to get in
[21:02] <tdonohue> +1 peterdietz. Correct, we'd never turn away code, unless it truly is outside of the scope of our "use cases" (but then we'd likely encourage it to be a third-party module/addon)
[21:03] <tdonohue> With 6.0, this does mean though that we likely should start doing some more active planning around "what do folks have ready?" in the coming weeks/months, and start to get a better sense of what that looks like at OR15 as well
[21:03] <peterdietz> hmm. reading the roadmap. Why on earth would you prioritize Solr stats.. I find it soo bad
[21:03] <hpottinger> re: prioritizing, let me just leave this here: https://www.bountysource.com/
[21:03] <kompewter> [ Bountysource ] - https://www.bountysource.com/
[21:04] <tdonohue> peterdietz: simply because we need *one* built in Stats engine (not two -- just like the two UI issue, two search/browse system issue, etc), and we already use Solr for "everything else"
[21:04] <tdonohue> peterdietz: but, yes, Solr stats would need enhancing big time
[21:05] <hpottinger> OR, we make progress on serializing usage events to a log file, and leave the job of processing that log up to 3rd party tools
[21:05] * aschweer_ (~andrea@89.75.69.111.dynamic.snap.net.nz) has joined #duraspace
[21:06] <tdonohue> People (DCAT folks, their bosses) want stats in the UI. So, that likely will mean a need for "built in" Stats, or Stats that can be auto-pulled in from an external tool (e.g. Google Analytics) so they "appear" in the UI.
[21:06] <aschweer_> or I finally get my act together and share our solr stats customisations - they need more work but are a lot better than default stats http://researchcommons.waikato.ac.nz/stats
[21:07] <kompewter> [ Usage Statistics ] - http://researchcommons.waikato.ac.nz/stats
[21:07] <aschweer_> anyway, those details are not something we need to figure out now :)
[21:07] <tdonohue> That's just the feedback I've heard (from DCAT mostly, as I'm attending all their meetings as well)
[21:07] <tdonohue> aschweer_: please do share your customizations!
[21:08] <aschweer_> thanks tdonohue, I'll try to find the time
[21:08] <aschweer_> anyway, sorry folks, I need to head to work. bye all!
[21:08] <tdonohue> I'm realizing we are overtime here. Any other immediate thoughts/questions? Again you are more than welcome to send things my way, or add them to the wiki directly, etc
[21:08] <hpottinger> bye
[21:08] <kompewter> see ya!
[21:08] * aschweer_ (~andrea@89.75.69.111.dynamic.snap.net.nz) Quit (Client Quit)
[21:09] * aschweer (~andrea@89.75.69.111.dynamic.snap.net.nz) Quit (Ping timeout: 250 seconds)
[21:09] * mhwood (~mhwood@adsl-99-1-96-171.dsl.ipltin.sbcglobal.net) Quit (Ping timeout: 250 seconds)
[21:10] <tdonohue> Ok, not hearing anything else, we'll close up the meeting for today. I'll still be around though for about 30mins or so, if something comes up
[21:11] <KevinVdV> Need to run
[21:11] * KevinVdV (~KevinVdV@d5153d041.access.telenet.be) Quit (Quit: KevinVdV)
[21:13] <hpottinger> Oh, shoot, I was going to bug KevinVdV about his SWORD PR
[21:15] <hpottinger> DSPR#850
[21:15] <kompewter> [ https://github.com/DSpace/DSpace/pull/850 ] - [DS-2131] SWORDv2 ingestion fails with NullPointerException when replacing a non archived item by KevinVdV
[21:15] <peterdietz> I would say, the direction I would want to push DSpace is preservation. The ability to migrate content to other formats. i.e. submit doc, then DSpace will upgrade that to docx / pdf. And also allow documents to be disseminated in other formats
[21:16] <peterdietz> Make it easy to see how much your content is being checksumed, see that there are safe replicas somewhere
[21:16] <tdonohue> peterdietz: some of that is actually detailed in use cases. Here's the ones that have been "tagged" Preservation related: https://wiki.duraspace.org/label/DSPACE/uc-preservation
[21:17] <kompewter> [ Labelled content - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/label/DSPACE/uc-preservation
[21:17] <tdonohue> but, you are welcome to add more use cases. There has been some discussion though about whether DSpace should attempt to compete with full Preservation workflow systems, or just do the "basics" and provide integrations with other systems
[21:17] <hpottinger> A "preservation dashboard"
[21:18] <peterdietz> Those preservation use cases are penned by MPW, so I/we have likely shared similar thoughts on these
[21:20] <tdonohue> Just so folks know in general, anyone is welcome to still add more "use cases" (or add comments/enhancements or "votes" to existing ones). I'm still "watching" those, but as of now, all 120+ use cases have been analyzed, categorized & assigned an initial priority: https://wiki.duraspace.org/display/DSPACE/Use+Case+Analysis
[21:20] <kompewter> [ Use Case Analysis - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Use+Case+Analysis
[21:20] <tdonohue> Anyone can add more use cases here though (and there's even a button to create a template page): https://wiki.duraspace.org/display/DSPACE/Use+Cases
[21:20] <kompewter> [ Use Cases - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Use+Cases
[21:20] <peterdietz> My DSpace 6/7/8 goals are to make DSpace deliver on all the ways I've described it to some random person over cocktails. So that's my bring what you have.
[21:22] <hpottinger> if we're going into chat mode, let's go to #dspace
[21:49] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:22] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.