Timestamps are in GMT/BST.
[0:04] * kshepherd2 (~kim@203.160.115.179) Quit (Ping timeout: 264 seconds)
[6:51] -sendak.freenode.net- *** Looking up your hostname...
[6:51] -sendak.freenode.net- *** Checking Ident
[6:51] -sendak.freenode.net- *** Found your hostname
[6:51] -sendak.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:34] * kshepherd2 (~kim@121-99-35-254.bng1.nct.orcon.net.nz) has joined #duraspace
[13:02] * kshepherd2 (~kim@121-99-35-254.bng1.nct.orcon.net.nz) Quit (Ping timeout: 264 seconds)
[13:23] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[17:37] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[19:13] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[19:51] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-02
[20:01] <kompewter> [ DevMtg 2014-04-02 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-02
[20:02] <tdonohue> I'll admit, the agenda is mostly a "guess" for today. It's a bit light on actual substance, but I figured it'd be good to check in on statuses, and see what discussions come up
[20:03] <tdonohue> First off though, I just wanted to remind folks that we are looking for volunteers for the 5.0 Release Team. We also need to start working towards a tentative 5.0 Release schedule (which that Release Team can help establish or rework as they see fit)
[20:04] <tdonohue> There's an example 5.0 release schedule already up at: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[20:04] <kompewter> [ DSpace Release 5.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[20:04] <tdonohue> Though that schedule I believe is just a copy of last year's 4.0 schedule -- but the timeframes will likely be similar this year, even if the exact dates change slightly
[20:05] <hpottinger> I can volunteer for RT, I've been instructed that I am not to volunteer for RC, though.
[20:05] <tdonohue> (e.g. chances are the 5.0 PR deadline will be around late Sept or early Oct)
[20:06] <tdonohue> hpottinger: sounds great! :)
[20:06] <PeterDietz> /offtopic -- I can share a link to a rails + DSpace REST project we've been working on -- http://dspace-rails.herokuapp.com/communities
[20:06] <kompewter> [ Single Item ] - http://dspace-rails.herokuapp.com/communities
[20:06] <hpottinger> I've got a re-worked schedule on my desk at work, I'm working at home today, mostly the deadlines map to roughly the same dates as for 4.0
[20:06] <tdonohue> I'm obviously not expecting us to figure out a 5.0 release team today...just wanted to remind folks that we're still looking
[20:08] <tdonohue> The only other semi-official topic for today. Just wanted to check in on the 3.x and 4.x platforms. It seems like there may be a 4.2.... I don't recall if we ever decided on a 3.3?
[20:08] <mhwood> helix84 argued for a 3.3, and I think I volunteered to do one (unless a 3.x RT member wants this).
[20:08] <tdonohue> (With all my recent travels, I've only been in this meeting every other week for a while...so I feel like I don't even know all the latest with 3.x and 4.x. Luckily I don't have any more trips for some time)
[20:10] <tdonohue> here's what seems to be in 3.3, according to JIRA: https://jira.duraspace.org/browse/DS/fixforversion/11841
[20:10] <kompewter> [ DSpace: 3.3 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11841
[20:10] <hpottinger> helix84 has put in the work of backporting stuff to the 3.x branch
[20:10] <tdonohue> And also for 4.2, according to JIRA: https://jira.duraspace.org/browse/DS/fixforversion/11840
[20:10] <kompewter> [ DSpace: 4.2 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11840
[20:10] <mhwood> There are 10 issues scheduled for 4.2
[20:10] <hpottinger> we might want to look for anything else that "needs" backporting
[20:11] <mhwood> I just pulled a DOI fix into 5.0 that should also go into 4.2 if there is one.
[20:12] <tdonohue> Oh, that's right. We really do need a 3.3...specifically for DS-1536 (which while it doesn't affect everyone, is a major pain for those it does affect)
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1536 ] - [DS-1536] having a DOT in handle prefix causes identifier.uri to be cut off when being created - DuraSpace JIRA
[20:12] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:12] <mhwood> Hmmm, project = DSpace AND fixVersion = "3.3" AND status != Closed ORDER BY status only turns up one issue.
[20:13] <hpottinger> and that issue is....
[20:14] <mhwood> DS-1958
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-1958 ] - [DS-1958] Discovery OutOfMemoryError when indexing Large Bitstreams. - DuraSpace JIRA
[20:14] <mhwood> Don't know how to write "'3.3' in fixVersion" properly.
[20:14] * richardrodgers (~richardro@18.189.115.43) has joined #duraspace
[20:14] <hpottinger> created 14 minutes ago...
[20:15] <mhwood> Wow, I thought it looked unfamiliar.
[20:15] <tdonohue> 1958 is marked "trivial" so hopefully we have a PR coming soonish from @mire as well
[20:15] <hpottinger> by the most elusive mdiggory...
[20:15] <tdonohue> But, yes, it sounds like 3.3 might want to wait for 1958
[20:16] <hpottinger> hey, look, it's richardrodgers and aschweer!
[20:16] <richardrodgers> hey all
[20:18] <aschweer> good morning
[20:19] <tdonohue> So, to summarize. 3.3 sounds like it needs to happen (may want to wait on 1958 which sounds bad), and 4.2 sounds like it may happen at some point too (as 1958 would be good to fix there too)
[20:20] <tdonohue> I mostly just wanted to see where things stand with 3.x/4.x That's "good enough" for me for now. I personally would want to see DS-1958 get squashed though soonish
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1958 ] - [DS-1958] Discovery OutOfMemoryError when indexing Large Bitstreams. - DuraSpace JIRA
[20:21] <tdonohue> Unless anyone has anything else related to 3.x or 4.x, we can move along to other topics :)
[20:22] <tdonohue> The rest of my rough "agenda" really is up-in-the-air. Honestly, I'm opening the floor to whatever you all would like to discuss. I had mentioned some possible topics of "feature ideas/updates" for 5.0, or even talk about whats going on with the DSpace Vision discussions (if my recent email brought up questions)
[20:23] <hpottinger> 3.x/4.x: dates?
[20:23] <tdonohue> Anyone have anything to discuss or bring up?
[20:24] <PeterDietz> The only thing I have, I linked previously is the rails+rest project: http://dspace-rails.herokuapp.com/item/6210
[20:24] <kompewter> [ Single Item ] - http://dspace-rails.herokuapp.com/item/6210
[20:25] <tdonohue> hpottinger: good question. I suspect that's more a question for whoever is volunteering to cut the releases (which need not necessarily be mhwood again, unless he wants to). Seems like 3.3 & 4.2 *could* be released as soon as sometime in the next month.
[20:26] <tdonohue> PeterDietz: Interesting! Is that built against the 4.x REST API?
[20:26] <hpottinger> If mhwood is willing to cut the release, I say he gets to pick the dates.
[20:26] <PeterDietz> Its currently pegged against Ohio State's DSpace, which I've backported the same 4.x rest api to work on. (Note: OSU is running 1.8.x + rest)
[20:27] <PeterDietz> ...so, it should work exactly correct against another 4.x DSpace / 1.0 DSpace REST
[20:27] <tdonohue> hpottinger ++ I agree, the person doing the work can obviously select the dates. Seems like we are "waiting" on 1958, so we may need to set a date at least a week out.
[20:31] <hpottinger> sent mdiggory a note just now re 1958
[20:31] <tdonohue> So, with 3.3 and 4.2, do we have someone willing to cut those releases? Beyond that, we'll also need some (minimal) documentation updates and announcements to lists.
[20:32] <hpottinger> cutting a release isn't nearly as exotic as it sounds, the script just runs, any takers?
[20:34] <mhwood> I think I already volunteered for 3.3 unless someone else wants it. Maybe someone else on the 4_x RT could take 4.2?
[20:34] <hpottinger> I'll take 4.2, it'll be a party
[20:35] <tdonohue> Ok. sounds good. Thanks, mhwood & hpottinger. So, then it's up to you two to set the dates. It looks like 3.3 is more "ready" than 4.2 (just waiting on 1958). 4.2 seems to still have quite a few open tickets which we either need to complete or reschedule
[20:35] <hpottinger> (but if anyone else wants to run the script, let me know)
[20:37] <mhwood> I have a daily note on my calendar about 3.3. I'll keep an eye on Ds-1958 progress.
[20:37] <tdonohue> ok, sounds fine. We can revisit these later on then.
[20:37] <hpottinger> the end of 1958 says "The following change assures a consistent memory footprint for Solr Indexing." I suspect a PR is incoming
[20:38] <tdonohue> Any other topics or things folks which to discuss? PeterDietz also mentioned his rails app above
[20:38] <richardrodgers> Since hpottinger asked about it in connection with https://jira.duraspace.org/browse/DS-1871, I'm happy to shepherd media filters as curation tasks to 5.0. The work is here: https://github.com/richardrodgers/ctask/tree/master/mediafilter If anyone has additional functional requirements, I'm all ears.
[20:38] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1871,
[20:38] <kompewter> [ ctask/mediafilter at master · richardrodgers/ctask · GitHub ] - https://github.com/richardrodgers/ctask/tree/master/mediafilter
[20:38] <kompewter> [ https://jira.duraspace.org/browse/DS-1871 ] - [DS-1871] UI support to call filter-media - DuraSpace JIRA
[20:39] <hpottinger> I added a link to that work as a comment on 1871 (thanks, richardrodgers!) and marked the ticket as "low_hanging_fruit"
[20:39] <mhwood> Thanks richardrodgers.
[20:39] <PeterDietz> media-filter to curation-task feels long overdue. Thanks for tackling that
[20:39] <tdonohue> awesome. Thanks richardrodgers. That'd be a great addition to 5.0
[20:40] <tdonohue> richardrodgers, should we assign 1871 to you then?
[20:40] <mhwood> We should look over the other periodic jobs to see if any are done that way only because we didn't have a better way.
[20:41] <richardrodgers> No problem - a big side-effect win is using Tika library - we suddenly get a whole bunch of additional formats we can extract text from..
[20:41] <hpottinger> ooh, cool
[20:41] <richardrodgers> tdonohue: sure, go ahead
[20:44] <hpottinger> TY, richardrodgers!
[20:44] <tdonohue> yes, thanks!
[20:45] <tdonohue> Any other updates / thoughts / questions from anyone else?
[20:45] <hpottinger> rails app, it's just a read-only UI, correct?
[20:46] <PeterDietz> hi hpottinger, yeah. Its talking to the DSpace 4.0 / DSpace REST API 1.0, so its using only what that other thing provides. Which is public - read only - anonymous
[20:47] <tdonohue> I'm assuming this rails app is really just an early proof of concept? Or are there any plans to move in that direction at OSU?
[20:47] <hpottinger> would be kinda cool if it fed new content in via SWORD
[20:47] <PeterDietz> I think we have some rails caching on it too. So, it won't make another API call, if rails has cached the response, not sure of the details of that one.
[20:49] <PeterDietz> Yeah, eventually these kick-the-tires apps (DSpace-REST-API-clients) will coalesce into needing to do things, such as edit, create, manage, perform actions. For now, I'm thinking that you might just have a login button, that changes your to your url for JSPUI/XMLUI
[20:50] <tdonohue> cool. makes sense
[20:50] <PeterDietz> ...but in the this-year time frame, I'm thinking that adding more functionality to DSpace REST is on my horizon. Richard has been active in that space too. Once your API supports features, the app can do things
[20:50] <PeterDietz> so DSpace 4.0 has REST 1.0, its possible that DSpace 5.0 could have an incompatible REST 2.0
[20:51] <PeterDietz> where DSpace REST 2, might be in a different structure, different endpoints, different auth, ...
[20:52] <tdonohue> Is there a reason to so drastically change things between REST 1.0 and REST 2.0?
[20:52] <PeterDietz> perhaps, I can look at having DSpace 5, have both DSpace 1.0 and DSpace 2.0, I haven't fully hashed the plan out
[20:52] <tdonohue> We obviously can do such major changes in a major release...but we'd need to document how one migrates from REST 1.0 -> 2.0
[20:53] <mhwood> Because it wouldn't be 2.0 if it didn't break with 1.x?
[20:53] <richardrodgers> NIce thing about REST APIs - you can version em and support several..
[20:53] <PeterDietz> no need, per se. Just that my riffs, Anja's riffs, and Richard's riff, all have slightly different response structure. I don't see any conclusive pro's/con's to any. Perhaps sticking with the most compatible structure has some merit
[20:54] <tdonohue> I'm just wondering about the reasons why we are jumping to "different structure, different endpoints, etc". If there are good reasons / use cases, then by all means we can do that. I just didn't want to encourage drastic redesign just cause "we felt like it"
[20:55] <hpottinger> well... there are probably reasons behind our feelings... :-)
[20:55] <tdonohue> But, I do agree, we can version REST or make drastic REST changes in 5.0. I just want there to be good reasons why :)
[20:55] <tdonohue> (so that we can explain them to the users of REST who are bound to ask those questions)
[20:55] <PeterDietz> heh, reminds me of a ruby gem we were using. The maintainer pulled a version from rubygems.org, because he felt like it. He then version-bumped, and added the same exact thing back a day later. Needless to say, our app wouldn't bundle/compile for a day
[20:57] <PeterDietz> I think we'll find a route that makes sense for everyone. i.e. this rails app, or my play! framework consumers could hit DSpace 5 + REST@1.0,... What richard was saying about support multiple versions
[20:58] <PeterDietz> demo.dspace.org/rest/v1/items.json vs demo.dspace.org/rest/v2/works.json you could upgrade the underlying DSpace 4.x to 5.x, but so long as the rest module can do v1 and v2, no heartburn for anyone
[20:59] <tdonohue> PeterDietz. Yep, that makes sense...we can even potentially "deprecate" /v1/ in DSpace 5.0 (to warn users to move to /v2/)
[21:00] <hpottinger> we still support SWORDv1, correct?
[21:00] <tdonohue> (that would make our jobs easier going forward, so we don't have to *continually* maintain two versions of the REST API forever)
[21:01] <tdonohue> hpottinger: yes, but SWORD is a bit different.. There are not enough SWORDv2 tools out there (yet), which is why we still have SWORDv1 and SWORDv2
[21:03] <hpottinger> my point was that we're currently already supporting two service APIs for the same type of service, we'll be fine if we support more than one REST API
[21:06] <tdonohue> I disagree (says the guy who hates supporting multiple versions of things forever and ever) ;)
[21:07] <tdonohue> But, in any case, we can figure that out later...I just don't like the idea of have REST 1.0 stick around forever just cause "someone might still be using it"... it gets us into another LNI scenario
[21:08] <tdonohue> So, I've come to the 'frame of mind' that I'd rather deprecate often, see if there are complaints, and then remove support....but again, that's only my opinion and I obviously can be out-voted by the majority
[21:09] <mhwood> No reason we can't ask, from time to time: are you still using X version Y? what would it take for you to move to version Z?
[21:10] <tdonohue> Noticing now that we're in overtime here & I admit I have to leave shortly (head into lurking mode).
[21:10] <mhwood> Yeah, I have to go too.
[21:10] <mhwood> 'bye, all.
[21:10] <PeterDietz> yeah. If we had a way to keep track of who is using what, i.e. to generate an API-key, please give us your email address. Then you could email people that have keys to deprecated versions, or be able to give your external users a heads up before maintenance..
[21:10] <tdonohue> mhwood ++ Yep, I agree. Deprecation sometimes forces the point even more than a survey would..but the same idea
[21:11] <hpottinger> I'm inclined to agree, in general, about supporting older code, as long as we don't deprecate merely because we fear potential future work, let's deprecate for good, functional, reasons
[21:11] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:11] <richardrodgers> gotta run also - bye all
[21:11] * richardrodgers (~richardro@18.189.115.43) Quit (Quit: richardrodgers)
[21:12] <tdonohue> So, I'm going to close up the meeting now as folks obviously need to head out (as do I). I will be lurking around here though, if any other topics come up. I just have a few other things I need to try and get done here before calling it a day :)
[21:14] <hpottinger> my hunch was right: DSPR#515
[21:14] <kompewter> [ https://github.com/DSpace/DSpace/pull/515 ] - DS-1958 Fix SolrLogger Memory Error by mdiggory
[21:18] <hpottinger> who wants to review 515?
[21:30] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:49] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Quit: Later, taterz!)
[22:33] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[23:26] * edInCo (~smuxi@seta.coalliance.org) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.