Timestamps are in GMT/BST.
[6:37] -cameron.freenode.net- *** Looking up your hostname...
[6:37] -cameron.freenode.net- *** Checking Ident
[6:37] -cameron.freenode.net- *** Found your hostname
[6:38] -cameron.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:18] * cknowles_ (uid98028@gateway/web/irccloud.com/x-jpfcidrujepqpxle) has joined #duraspace
[7:42] * jm_ (57c568d1@gateway/web/freenode/ip.87.197.104.209) has joined #duraspace
[8:53] * cknowles_ is now known as cknowles
[12:29] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:01] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Ping timeout: 246 seconds)
[13:02] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:10] * tdonohue (~tdonohue@c-73-45-154-218.hsd1.il.comcast.net) has joined #duraspace
[13:28] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) has joined #duraspace
[15:07] * kdweeks (~Adium@2001:468:c80:a103:4db:caa1:461:a8e5) has joined #duraspace
[19:34] * kdweeks (~Adium@2001:468:c80:a103:4db:caa1:461:a8e5) Quit (Quit: Leaving.)
[20:00] <tdonohue> Hi all, it's time for the DSpace DevMtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-08
[20:00] <kompewter> [ DevMtg 2015-07-08 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-08
[20:01] <tdonohue> First thing up is 5.3...which we are closing in on. We mostly just need a few good testers for PRs: https://jira.duraspace.org/browse/DS/fixforversion/12840
[20:01] <kompewter> [ DSpace: 5.3 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/12840
[20:02] <tdonohue> Most of these PRs have at least one +1...they just need another. Over the last few days I've been testing most myself, and added in my own +1s
[20:02] <tdonohue> argh, wrong link. Here is the PR list: https://github.com/DSpace/DSpace/milestones/5.3
[20:02] <kompewter> [ Issues · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/milestones/5.3
[20:03] <tdonohue> we have 7 open PRs ready for 5.3. The highest priority ones are DSPR#982, DSPR#981 and DSPR#975. But, others would be good additions too
[20:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/982 ] - DS-2593 : Ensure a "tombstone" is left for withdrawn items in OAI-PMH. Fix other minor, obvious OAI bugs. by tdonohue
[20:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/981 ] - DS-2602 : Fix Title/Date browsing, also properly escape special characters in Solr by tdonohue
[20:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/975 ] - DS-2614: Ignore custom resource policies for unfinished items by pnbecker
[20:05] <tdonohue> Anyone willing to volunteer to give a secondary review of any of these? All three of these high priority ones have one Committer +1 already
[20:05] <hpottinger> It's easy to test PRs in Vagrant-DSpace, hint hint
[20:06] * kshepherd will test 982 and 981 tonight (work desktop not powerful enough for VMs / vagrant testing etc)
[20:06] <tdonohue> Essentially this is the only thing standing between now and a 5.3 release. These three high priority PRs must get into 5.3. The others are "nice to have" but not really required.
[20:08] <tdonohue> No volunteers? Well, do we review these today then in this meeting? I'd just hate for these three PRs to sit around another week at this point. Seems like we are almost to 5.3
[20:09] <kshepherd> tdonohue, i'm volunteering to test the priority ones but have to wait for tonight when i'm at home
[20:09] <cknowles> I can test 943 (a nice to have) testing 982 my vagrant DSpace had memory issues
[20:09] <tdonohue> kshepherd: sounds good, I'd appreciate it! Tonight is honestly fine...I was just wanting to get reviewers for these this week
[20:10] <tdonohue> cknowles: thanks! Just as a warning, 943 kinda requires 981 (as Title/Date browsing is broken). So, you'd need to test it with 981 in place as well, unfortunately
[20:11] <cknowles> I have 981 as tested that one already :)
[20:11] <tdonohue> just wanted to be sure :) Thanks
[20:13] <tdonohue> So, considering we are narrowing in on a 5.3 release, I wonder if we should set some goals here. For instance, it might be nice to schedule a tentative release date (say, Thurs, July 23?) and let the Committers know as well. Oh, and we'd need someone to cut the release
[20:14] <tdonohue> any volunteers to cut the release? Or any thoughts on a tentative release date? (Does July 23 sound reasonable?)
[20:15] <kshepherd> *tumbleweed*
[20:15] <kshepherd> (date sounds reasonable ;))
[20:15] <tdonohue> Yep, lots of quiet here today :)
[20:16] <tdonohue> Ok. We'll go with a tentative July 23(ish) then. It'd be nice to get these PRs tested before next week's meeting, if possible. That way we can finalize release plans next week
[20:16] <hpottinger> I'm going on vacation for a bit, so I'll be even less dependable than usual :-\
[20:18] <tdonohue> Any other bugs folks think we need to fix in 5.3 that I'm missing? If so, let me know
[20:18] <hpottinger> I'll be back on Monday July 20, so, if you don't have a conscript lined up by then, you can try your luck asking me, but I'm not volunteering now :-)
[20:19] <tdonohue> TODO July 20, convince hpottinger to cut the release after returning on a "vacation high"
[20:19] <tdonohue> :)
[20:19] <cknowles> :)
[20:19] <tdonohue> Ok, nothing else on 5.3 I'm hearing, so we'll move along
[20:19] <tdonohue> 6.0 Topics.
[20:19] <hpottinger> is DS-2527's proposed fix (DSPR#941) a "feature" or a "bugfix"?
[20:19] <kompewter> [ https://github.com/DSpace/DSpace/pull/941 ] - [DS-2527] Disable collection authorisation enumeration optimisation by default by rradillen
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-2527 ] - [DS-2527] Shibboleth Authentication don't read collections of special groups - DuraSpace JIRA
[20:20] <tdonohue> hpottinger: to me, that PR seems like a bug fix. It's turning off a "feature" which has been proven to be quite buggy (as we noticed in our JIRA backlog review prior to this meeting)
[20:20] <mhwood> Just changing a setting is not a new feature.
[20:21] <hpottinger> 941 is slated for 6, but, maybe it ought to be in 5.3?
[20:21] <tdonohue> The PR itself is tiny, and just switches the default value of an existing setting
[20:21] <tdonohue> 941 is slated for 5.3: DSPR#941
[20:21] <kompewter> [ https://github.com/DSpace/DSpace/pull/941 ] - [DS-2527] Disable collection authorisation enumeration optimisation by default by rradillen
[20:21] <hpottinger> well... hmm... (looks at scribbly notes, crosses some out)
[20:22] <hpottinger> is 941 "ok to merge" now?
[20:23] <tdonohue> It seems like it's tiny/obvious. I'd give my +1, but I've only looked at the code (haven't tested)
[20:23] <tdonohue> If someone is willing to give it a quick sanity check, I'd say it's "ok to merge"
[20:24] <tdonohue> (I.e. I'd prefer someone test the PR, make sure it does disable the feature by default).. It should looking at the code)
[20:24] <hpottinger> will do, 941 is immediately applicable in our environment, though I have to say I have not yet seen evidence of DS-2527
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-2527 ] - [DS-2527] Shibboleth Authentication don't read collections of special groups - DuraSpace JIRA
[20:25] <tdonohue> Thanks hpottinger
[20:25] <tdonohue> So, back to 6.0 topics
[20:26] <tdonohue> First, I just got word from @mire on a "tentative" date for the DSpace Service API webinar/meeting. They are suggesting Thurs, July 23 @ 15:00 UTC (which I now release is the release date I said for 5.3, but oh well)
[20:27] <tdonohue> Does that Day/Time seem reasonable. (Sorry, kshepherd, I know it isn't reasonable for you, but I'm working on recording the session)
[20:28] <kshepherd> yeah, that time is about as unreasonable as possible for me ;)
[20:29] <tdonohue> In any case, the next steps are for me to finalize the date with the folks who run our DuraSpace webinars... Then we can send out announcements and get it on everyone's schedules. So, if anyone is aware of immediate conflicts with that date/time, let me know
[20:30] <hpottinger> besides the 5.3 release date, no known conflicts
[20:31] <tdonohue> We can switch that 5.3 release date by a day one way or the other. It's my fault for not realizing that ;)
[20:32] <tdonohue> In any case, that's really the only "new" news I have for 6.0. We still need folks to volunteer time for the Release Team. We still need to start to gather features together, and also need help in getting Lucene-support refactored out
[20:33] * kshepherd is pretty nervous about trying any dev on master until he knows what will break / needs loads of refactoring / future learning curve re: the Big Service API Changes
[20:33] <tdonohue> Any other thoughts, ideas, topics to discuss with regards to 6.0? I have to admit, it's moving veeery sloooow thus far, and I'm hoping we can get it ramped up soon (perhaps the Service API change will kickstart us)
[20:33] <hpottinger> so there's a record of it somewhere, I've heard from Ryan Scherle at Dryad that they're willing to contribute the oath login work for 6.0
[20:33] <kshepherd> oath login - is that where a user makes a solemn promise that they *are* the eperson they claim to be? ;)
[20:34] <tdonohue> hpottinger: can you add that to the 6.0 Wish list? https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[20:34] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[20:34] * hpottinger scowls at the U key
[20:34] <hpottinger> s/oath/oauth/
[20:34] <kompewter> hpottinger meant to say: so there's a record of it somewhere, I've heard from Ryan Scherle at Dryad that they're willing to contribute the oauth login work for 6.0
[20:34] <tdonohue> haha. I missed the lack of a "u" there...good catch, kshepherd
[20:35] <mhwood> "oath login" is when you swear at the screen until it lets you in anyway.
[20:35] <kshepherd> with my recent work on ORCiD, i miiight be able to build off / collaborate with Ryan's OAuth work and do some cool ORCiD OAuth (read profile, populate eperson metadata)
[20:35] <kshepherd> but that's an idea i had literally 15 seconds ago
[20:35] <tdonohue> Sounds like an interesting idea though :)
[20:36] <tdonohue> btw, kshepherd, if there is specific other work you are thinking about (but waiting on Service API stuff for), it might be good to at least add it to the "wish list" as well as possible features for 6.0
[20:37] <kshepherd> well, i think we already know it - but extending coverage of REST API is going to be pretty necessary for supporting some potential prototypes in 7.0, and would just be a cool thing to do anyway
[20:37] <kshepherd> that's been my main "thing"
[20:38] <hpottinger> wishlist for 6 amended with Oauth plugin
[20:38] <tdonohue> kshepherd: to be honest, that doesn't seem like anything you'd need to wait on. REST will need some general updates for the Service API (if it is accepted), but that doesn't mean you couldn't still get the extensions built out nowish...and then we just swap out for the necessary new API calls later
[20:39] <tdonohue> and I do like that idea...it'd be good to enhance REST
[20:39] <kshepherd> ok
[20:40] <tdonohue> my understanding of the Service API stuff thus far (and I don't have a full understanding yet), is that it will just require swapping out some API calls for new ones in our various webapps. "Just" is probably the wrong word, as that could be a lot of work for some webapps though
[20:41] <hpottinger> so... what is this "service API" of which you speak?
[20:42] <tdonohue> haha. It's the thing being presented on July 23. It's kinda Hibernate + the beginnings of a Business Logic layer (in some ways). I've downloaded KevinVdVs code to play with it some, but I don't know it well enough to fully describe yet (but that's what July 23 webinar is about)
[20:42] <tdonohue> code is at: https://github.com/KevinVdV/DSpace/tree/dspace-service-api
[20:42] <kompewter> [ KevinVdV/DSpace at dspace-service-api · GitHub ] - https://github.com/KevinVdV/DSpace/tree/dspace-service-api
[20:43] <kshepherd> would it make sense to see about a new release of xoai with some fixes/improvements for use with dspace 6?
[20:43] <tdonohue> It's got a lot of new stuff in there though...I was just starting to browse it myself when I had a free hour or so
[20:44] <tdonohue> Good question, kshepherd. Yep, regarding XOAI, I'd *hope* we'd be ready for fixes/improvements with DSpace 6.
[20:45] <tdonohue> Unfortunately though, the XOAI news is, I haven't heard back from, Joao / Lyncode yet about XOAI. He previously agreed that it'd be good to move to the DSpace GitHub project. But, he's not responded when I asked him to do so. Hopefully to hear back soon
[20:45] <hpottinger> did we ever figure out where/how we'd manage releasing xoai?
[20:46] <tdonohue> hpottinger: yes, it'll be moved to "DSpace/XOAI" (assuming Joao is agreeable to it & responds). The Committers will then get control and we will release it under "org.dspace" for now.
[20:46] * kshepherd gets out his trusty Fork
[20:46] <kshepherd> ah, open source! :)
[20:47] <tdonohue> I will keep pestering Joao. If I still don't hear much for a while, we may need to rethink "forking" (though I'd rather not do that)
[20:48] <kshepherd> (i'm sure we'll here back from joao in time, just pointing out we don't really need anyone to move it, right? we can just take a copy and run with it :))
[20:48] <tdonohue> The reality of the situation though is that we need more control over XOAI, as it has bugs we cannot fix and they are affecting DSpace's OAI interface, and no one else is fixing them
[20:49] <tdonohue> kshepherd: yes, that's true. We could just fork it now
[20:50] <tdonohue> I just didn't want to jump to forking it, if we can just become the maintainers of the main codebase (since no one else is actively maintaining it, and it was created by Joao for DSpace)
[20:50] <kshepherd> the big change of package names etc. makes it feel a little bit like a fork anyway. but engagement with everyone is pretty ideal
[20:50] <kshepherd> yeah true
[20:51] <mhwood> Forking doesn't copy *everything*. Better to have a hand-over.
[20:51] <mhwood> No, I don't recall what isn't copied.
[20:52] <tdonohue> So, that's the latest on XOAI. I'm hoping to hear back from Joao soon, so we can work on getting some fixes for 6.0 ready. I'll keep you all posted though
[20:53] * aschwer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:53] <tdonohue> Anything else to discuss around 6.0 or possible features?
[20:53] <aschwer> morning all, sorry I'm late
[20:53] <tdonohue> Hi aschwer, are you related to aschweer?
[20:53] <tdonohue> :)
[20:53] <cknowles> Hi aschwer
[20:53] <aschwer> see I'm clearly not even awake enough to type my own name ;)
[20:53] <tdonohue> obviously not :)
[20:54] * aschwer is now known as aschweer
[20:54] <aschweer> better? ;)
[20:54] <mhwood> Much.
[20:54] <hpottinger> I've gotta run soon
[20:54] <tdonohue> So, not hearing anything else around 6.0 for now (But, please if you are interested in helping this release along, let me know!)
[20:54] <kshepherd> i wouldn't even manage to connect to IRC if i didn't already idle 24/7 ;)
[20:55] <tdonohue> Final topic for today is a small update on the RoadMap work / UI Prototyping.
[20:56] <tdonohue> Jonathan Markow & I will be starting up a "UI Working Group" (which anyone can attend the first meeting of) sometime in the next week. First meeting is not yet scheduled, but likely late July. From that, we'll establish a more formal Working Group (of volunteers) to help us establish the prototyping process and the decision making process, etc
[20:57] <tdonohue> So, I'll let you all know once we have a date ready. Jonathan will be sending out an initial email to folks who already expressed interest in taking part soon...and a broader email to mailing lists will be likely in the next week or so
[20:58] <tdonohue> As noted (last week as well), I've also started doing a (very rough) brain dump of what the Prototyping process may look like: https://wiki.duraspace.org/display/DSPACE/Prototyping+a+Future+UI
[20:58] <kompewter> [ Prototyping a Future UI - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Prototyping+a+Future+UI
[20:58] <tdonohue> That whole process though would be finalized by the Working Group. In the meantime, feedback is welcome
[20:59] <tdonohue> I also did list my "experiment" with Spring Boot as a possible DSpace UI (something I've played with for a few days last week) as a possible Prototyping platform
[20:59] <cknowles> https://drive.google.com/open?id=1fyiL5X_YXy6Kpj8u5eb4IG1uwXkOnVVAIPbOsf-MPaE the UI document kshepherd and I have been working on
[20:59] <kompewter> [ DSpace Functionality Mapping - Google Sheets ] - https://drive.google.com/open?id=1fyiL5X_YXy6Kpj8u5eb4IG1uwXkOnVVAIPbOsf-MPaE
[21:00] <tdonohue> That's all the latest updates I have
[21:00] <cknowles> Still a work in progress
[21:00] <kshepherd> yeh, our 'mapping' didn't turn out as clean and easy as we wanted, no real references to specific API calls, etc. yet
[21:00] <kshepherd> but references to existing REST coverage / gaps, for future planning
[21:00] <tdonohue> thanks cknowles & kshepherd! I'll have to dig into this a bit more
[21:00] <kshepherd> and functional notes
[21:01] <tdonohue> It looks pretty detailed already at a glance. Nice.
[21:03] <tdonohue> Any objections to me finding a place to link this up on the Wiki? Maybe from https://wiki.duraspace.org/display/DSPACE/Design+-+Single+UI+Project as a resource?
[21:03] <cknowles> Not all columns are complete for all rows etc etc
[21:03] <kompewter> [ Design - Single UI Project - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Design+-+Single+UI+Project
[21:03] <tdonohue> Yep, I see that. But, it is a good start
[21:03] <hpottinger> that's a pretty handy list
[21:03] <kshepherd> yep link it up
[21:03] <tdonohue> ok, will do!
[21:03] <mhwood> Nice. Thanks.
[21:04] <mhwood> Got to run. 'bye, all.
[21:04] <tdonohue> Any other thoughts or questions for today? (realizing we're a bit overtime, and I have to run soon too)
[21:04] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:04] <kshepherd> possible that special attention needed for those special classes liek AbstractDSpaceTransformer (JSPUI) and... all that XMLUI stuff
[21:04] <kshepherd> tdonohue: do you have 2min in #dspace before you run?
[21:05] <tdonohue> sure. I do
[21:05] <tdonohue> Ok, not hearing anything else here, we'll go ahead and close up today's meeting then.
[21:05] <cknowles> Bye
[21:06] <aschweer> bye all
[21:06] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[21:17] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:29] * awoods (~awoods@c-67-174-123-122.hsd1.co.comcast.net) has joined #duraspace
[21:30] * tdonohue (~tdonohue@c-73-45-154-218.hsd1.il.comcast.net) has left #duraspace
[21:34] * awoods_ (~awoods@c-67-174-123-122.hsd1.co.comcast.net) has joined #duraspace
[21:38] * awoods (~awoods@c-67-174-123-122.hsd1.co.comcast.net) Quit (Ping timeout: 246 seconds)
[21:38] * awoods_ is now known as awoods
[23:30] * awoods_ (~awoods@c-67-174-123-122.hsd1.co.comcast.net) has joined #duraspace
[23:33] * awoods (~awoods@c-67-174-123-122.hsd1.co.comcast.net) Quit (Ping timeout: 256 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.