Timestamps are in GMT/BST.
[3:45] * awoods_ (~firstname.lastname@example.org) has joined #duraspace
[3:48] * awoods (~email@example.com) Quit (Ping timeout: 250 seconds)
[4:11] * awoods__ (~firstname.lastname@example.org) has joined #duraspace
[4:14] * awoods_ (~email@example.com) Quit (Ping timeout: 246 seconds)
[4:16] * awoods_ (~firstname.lastname@example.org) has joined #duraspace
[4:20] * awoods__ (~email@example.com) Quit (Ping timeout: 255 seconds)
[5:21] * Carlos (~firstname.lastname@example.org) has joined #duraspace
[5:21] * Carlos is now known as Guest90748
[5:25] * Guest90748 (~email@example.com) Quit (Ping timeout: 246 seconds)
[6:23] * kimiora (~firstname.lastname@example.org) has joined #duraspace
[6:43] -holmes.freenode.net- *** Looking up your hostname...
[6:43] -holmes.freenode.net- *** Checking Ident
[6:43] -holmes.freenode.net- *** Found your hostname
[6:43] -holmes.freenode.net- *** No Ident response
[6:43] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:43] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:43] * Set by cwilper!ad579d86@gateway/web/freenode/ip.184.108.40.206 on Fri Oct 22 01:19:41 UTC 2010
[7:07] * pbecker (~email@example.com) has joined #duraspace
[9:03] * cknowles (uid98028@gateway/web/irccloud.com/x-vtwjetyjrvmteyob) has joined #duraspace
[9:05] * awoods__ (~firstname.lastname@example.org) has joined #duraspace
[9:08] * awoods_ (~email@example.com) Quit (Ping timeout: 244 seconds)
[12:16] * awoods_ (~firstname.lastname@example.org) has joined #duraspace
[12:19] * awoods__ (~email@example.com) Quit (Ping timeout: 255 seconds)
[12:21] * cknowles (uid98028@gateway/web/irccloud.com/x-vtwjetyjrvmteyob) Quit (Quit: Connection closed for inactivity)
[12:26] * mhwood (firstname.lastname@example.org) has joined #duraspace
[12:48] * awoods_ is now known as awoods
[13:14] * tdonohue (~email@example.com) has joined #duraspace
[13:35] * cknowles (uid98028@gateway/web/irccloud.com/x-mvhplrnxwzqbhnpr) has joined #duraspace
[14:53] <tdonohue> REMINDER: DSpace DevMtg starts at the top of the hour (~7mins) here. Agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-15
[14:53] <kompewter> [ DevMtg 2015-07-15 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-15
[15:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-15
[15:02] <kompewter> [ DevMtg 2015-07-15 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-15
[15:02] <tdonohue> The primary topic for today is obviously the 5.3 release. We are zeroing in on a "ready release", and (as you may have noticed), I've just gone in myself and merged some approved PRs this morning
[15:03] <tdonohue> Still, here is our list of outstanding PRs which are currently flagged for possible inclusion in 5.3: https://github.com/DSpace/DSpace/milestones/5.3
[15:03] <kompewter> [ Issues · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/milestones/5.3
[15:04] <tdonohue> There's only 5 left here, and there's a 2-3 more in that list that likely could be merged very soon
[15:04] <tdonohue> The highest priority (and the last of the "must haves" for 5.3) is DSPR#982
[15: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
[15:05] <tdonohue> This one has general approval, but kshepherd had a few minor suggestions that could make it even better. I admit, I haven't had a chance to review kshepherd's thoughts much yet...but I planned to do so today
[15:06] <tdonohue> At the very least, I think this is "ready to merge" (unless there are objections). But, I want to see if any of kshepherd's suggestions are "quick fixes" which would be worth considering *in addition*
[15:07] <tdonohue> thoughts on this? (Also checking to be sure I'm not talking to myself here!)
[15:08] <mhwood> I'm here. Trying to formulate a useful thought.
[15:08] <pbecker> I'm half-eyed here.
[15:09] <pbecker> (working on getting #983 ready for 5.3 ;-))
[15:10] <tdonohue> I think kshepherd's note about updating PR to change "DSpaceAuthorizationFilter" might make sense...as it will ensure these "tombstone" records also are listed in "ListIdentifier" requets (and not just requests for "GetRecord" which only grabs one record at a time). So, for 982, I'll dig into it a bit more today and report back. If it's easy, I'll do this addition. Otherwise, I say we merge & improve post-5.3
[15:10] <mhwood> kshepherd's first alternative sounds like a quick fix, but the third sounds like the *right* fix.
[15:11] <mhwood> However I know next to nothing about the code here or this aspect of the protocol.
[15:11] <tdonohue> mhwood: I admit, I also need to dig in to understand these options. I'll do so later today and I can report back via a PR comment on what seems "doable" or if we just open up a new ticket for post-5.3
[15:12] <tdonohue> So, moving along to other PRs. Since they are so few, it might just be worth doing a quick update on each (to see if we can find a tester as needed).
[15:13] <tdonohue> DSPR#973 -> this is the one that pbecker is working on a quick fix to. It's nearly ready to go, and I'll gladly test it again once it is ready
[15:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/973 ] - DS-2358: Preserves custom policy rules during versioning by pnbecker
[15:14] <tdonohue> It's actually a very minor fix though, so it seems like it could be merged once verified again
[15:14] <tdonohue> next is DSPR#961. Another very minor fix. Was tested by kshepherd. Seems like it could be merged as well (code looks reasonable)
[15:14] <kompewter> [ https://github.com/DSpace/DSpace/pull/961 ] - fixed dots in upper pagination by pablobuenaposada
[15:15] <tdonohue> (Sidenote: If anyone disagrees with my analysis on this PRs, please do speak up...especially if you disagree about whether they seem merge-able or not.)
[15:15] <mhwood> Indeed, it's a tiny change in 961.
[15:16] <tdonohue> DSPR#943 seems like it needs more testing. It has verification tests from cknowles, and some comments from kshepherd here again that it doesn't quite fix all the problems (but is better than current behavior)
[15:16] <kompewter> [ https://github.com/DSpace/DSpace/pull/943 ] - DS-2571 Fix jumping to value in descending browse by aschweer
[15:16] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[15:17] <tdonohue> So, if anyone has time in the coming days, more effort on 943 (testing & feedback) might be a good place to help out
[15:18] <tdonohue> The last on the list is DSPR#941. Again a tiny (configuration) change. Has verification from kshepherd again (who's done an awesome job helping test!). Seems like it could be merged as well, and offers a quick fix to the Collection authorization "optimization" code issues
[15:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/941 ] - [DS-2527] Disable collection authorisation enumeration optimisation by default by rradillen
[15:21] <tdonohue> SUMMARY: Looks like we have two PRs which look mergeable (961, 941), two that have committers looking at minor enhancements (982, 973), and one that may need more help (943)
[15:21] * kimiora (~firstname.lastname@example.org) Quit (Read error: Connection reset by peer)
[15:21] <tdonohue> Does that sound right? Anyone willing to help out on 943 a bit more (testing or looking more at kshepherd's feedback)?
[15:23] <mhwood> 941 is a tiny change to a default and makes sense. I also agree with kshepherd's comment about documenting defaults in the config., but maybe that should be a new issue to generally clean up the config. commentary, after settling on a convention.
[15:24] <tdonohue> mhwood: yea, I agree with kshepherd's notes too (for the future). But, for 941, it actually does document the default value in the config...but the commented out configuration shows the *non-default* value.
[15:24] <pbecker> I just changed #973, building now. As soon as the build went through I will test and push it. I expect 973 to be merged by the end of the day (if tdonohue has time to test it again).
[15:25] <tdonohue> and +1 to reviewing our configs across the board to clean up comments, etc. I think this may happen "naturally" anyways as we move towards enhancing Configuration (dynamic and Admin UI based)
[15:26] <tdonohue> pbecker: I can make time to test 973 today, I think (tomorrow at the latest). In any case, we should be able to get it merged this week
[15:26] <tdonohue> and thanks, pbecker!
[15:27] <tdonohue> Ok, so we are closing in on the 5.3 release. We had set a tentative date of sometime next week (around July 23rd). It seems like we are still on schedule for that, which is great
[15:27] <pbecker> I have to thank for testing and reviewing.
[15:28] <tdonohue> It seems like the goal this week (hopefully by Fri) should be to get the rest of these PRs either merged or rescheduled (if needed), so that we can use next week to test 5.3 and do release preparations.
[15:30] <tdonohue> So, if anyone has time to help with this, please do let me know. I'm planning to also throw some time towards trying to test/merge PRs, but could use some help if anyone is willing to "claim" a PR or two.
[15:31] <pbecker> have to leave the meeting, sorry.
[15:31] <tdonohue> bye pbecker, we'll talk to you later
[15:32] <tdonohue> Ok. So, I think that wraps up 5.3 updates / status. Unless anyone has any questions or final thoughts?
[15:32] <mhwood> Apparently not.
[15:32] <tdonohue> nope :)
[15:33] <tdonohue> OK, moving along to 6.0 updates/discussion
[15:34] <tdonohue> As announced to dspace-devel, we have a "Special Topics" meeting next week (on Thurs, July 23 @ 15:00UTC) to talk about the @Mire "Services API + Hibernate" project that KevinVdV has been working on. http://dspace.2283337.n4.nabble.com/Special-Topic-Meeting-DSpace-quot-Services-API-quot-project-July-23-15-00-UTC-td4678814.html
[15:34] <kompewter> [ DSpace - Devel - Special Topic Meeting: DSpace "Services API" project - July 23 @ 15:00 UTC ] - http://dspace.2283337.n4.nabble.com/Special-Topic-Meeting-DSpace-quot-Services-API-quot-project-July-23-15-00-UTC-td4678814.html
[15:35] <tdonohue> This meeting is in *addition* to our normal developer meeting, which will be on West, July 22 @ 20:00UTC (as normal). Unfortunately, if we want to get 5.3 out the door, I think we still need to have the normal DevMtg
[15:36] <tdonohue> But, I'd encourage everyone to join this Special Topics meeting. It'll be via Adobe Connect (so that Ben Bosman & Kevin can present the work visually & we can do a live Q&A). It'll also be recorded so you can watch it later, if you cannot attend
[15:36] <mhwood> Planning to be here for both. Hopefully my meeting at 1400 Thursday won't run long.
[15:36] <mhwood> Ah, that means I'll have to see if I can get Connect working at home.
[15:37] <tdonohue> Yes, there are some instructions for testing Adobe Connect in the dspace-devel invitation email (linked above). So, you may want to test out your setup prior to the meeting
[15:37] <mhwood> Just sent myself a note about that, thanks.
[15:39] <tdonohue> Beyond that, regarding 6.0, most of the status is the same. But, I will mention that I added a new project for consideration to the 6.0 "wishlist" that I've been playing with: DS-2654
[15:39] <kompewter> [ https://jira.duraspace.org/browse/DS-2654 ] - [DS-2654] Reloadable Configurations via Apache Commons Configuration - DuraSpace JIRA
[15:40] * kshepherd (~email@example.com) has joined #duraspace
[15:40] <tdonohue> If anyone else has 6.0 updates/notes they'd like to share, please feel free to also do so.
[15:40] <kshepherd> hi all
[15:40] * kshepherd got meeting time wrong again :P
[15:41] <tdonohue> kshepherd? Wow, this is early for you! :)
[15:41] <kshepherd> heh, yep
[15:41] <mhwood> Drat, Connect insists on real Flash Player, not Shumway. I may have to reinstall that bug farm to join the meeting.
[15:41] * cknowles (uid98028@gateway/web/irccloud.com/x-mvhplrnxwzqbhnpr) Quit (Quit: Connection closed for inactivity)
[15:42] <tdonohue> kshepherd - Thanks for all your PR testing for 5.3. I noted earlier that you've been doing an excellent job chipping in on testing & feedback
[15:42] <kshepherd> np, hope my comments aren't too verbose
[15:43] <mhwood> Right on target, I think.
[15:43] <tdonohue> kshepherd: nope, they make sense, and all are good observations. The question is now whether we just create new tickets for those (for post-5.3), or if some are "doable" as quick-fixes in 5.3
[15:44] <tdonohue> So, honestly, for this last 15mins, I don't have any other topics of note in our agenda. We've talked 5.3. I did my few updates for 6.0. Anyone have other topics/thoughts/questions to discuss today?
[15:46] <kshepherd> i just checked the logs - i might submit a PR for 6.0 that does the *.cfg "fix up commented defaults" thing for consideration / voting, since a few seemed to agree with that idea?
[15:46] <tdonohue> Nothing? :) Come on... what are you all working on these days? Or, anyone want to chat about DS-2654 (my latest little experiment which looks to be showing some promise)
[15:46] <kompewter> [ https://jira.duraspace.org/browse/DS-2654 ] - [DS-2654] Reloadable Configurations via Apache Commons Configuration - DuraSpace JIRA
[15:47] <tdonohue> kshepherd: that sounds like worthwhile cleanup. So, go for it.
[15:47] <kshepherd> reloadable configs sounds cool!
[15:47] <mhwood> Config fixup would be welcome, I think. Do we have general agreement on that convention, though?
[15:48] <kshepherd> mhwood: yeah i'm not sure if there really *is* a convention anymore, but i could always throw it out there and see what people say
[15:48] <kshepherd> maybe it should be a dspace-tech email before it's a PR?
[15:49] <mhwood> There is a convention if the dev.s agree that there is one. Yes, an email would be the way, I think.
[15:50] <tdonohue> for a "convention" it also might be worth looking at what other OS systems do. I think many other systems do what you described in the PR comment, kshepherd. But, yea, I agree, an email thread seems reasonable.
[15:51] <mhwood> Do we have a place to document this convention for dev.s?
[15:52] <tdonohue> We have "code contribution standards" (which are not always well adhered to, but they do exist). Here: https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-CodeContributionStandards
[15:52] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-CodeContributionStandards
[15:52] <tdonohue> (ugh, some of those are outdated. "Java 1.6 compliant")
[15:53] <kshepherd> hehe
[15:53] <tdonohue> But, when people ask "how do I contribute code", I always point them at that wiki page, which also includes those "standards"
[15:53] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: Leaving)
[15:54] <kshepherd> most still look good
[15:54] <tdonohue> yep, most are OK. Just need some minor updates here & there
[15:55] * tdonohue writes it on my ToDo list to review this page again sometime soonish
[15:55] <tdonohue> I'm going to need to head out to another meeting in ~5mins
[15:56] <tdonohue> Any final thoughts for today?
[15:56] <kshepherd> quick question/thought about media filter and curation tasks...
[15:57] <kshepherd> if we have new media filter stuff coming in, should we think about making them curation tasks instead, or is it better to stick to the actual mediafilter way of doing things?
[15:58] <mhwood> I think I'm not the first to suggest that mediafilter should *become* a curation task.
[15:58] <tdonohue> I think the issue is that it's hard to make that "requirement" until we convert existing media filters to curation tasks. Otherwise you end up with an odd scenario where some are run via "filter-media" and other are run via "curate". But, I agree with that direction
[15:59] <tdonohue> I'm also +1 media filters moving entirely to curation tasks.
[15:59] <kshepherd> mm ok yeh sounds like my thinking
[15:59] * tdonohue notes unfortunately I have to head out to another meeting. I'll check the logs later though
[16:00] * kshepherd might be able to fit a couple of hours sleep in before he has to leave for work ;)
[16:01] <mhwood> Sounds like "meeting adjourned" then. Thanks all!
[16:01] <kshepherd> cheers all
[16:13] * kshepherd (~firstname.lastname@example.org) Quit (Quit: leaving)
[16:20] * pbecker (~email@example.com) Quit (Quit: Leaving)
[17:21] * mhwood (firstname.lastname@example.org) Quit (Ping timeout: 250 seconds)
[17:22] * mhwood (email@example.com) has joined #duraspace
[19:26] * awoods (~firstname.lastname@example.org) Quit (Ping timeout: 256 seconds)
[19:30] * awoods (~email@example.com) has joined #duraspace
[19:57] * awoods (~firstname.lastname@example.org) Quit (Ping timeout: 256 seconds)
[20:08] * awoods (~email@example.com) has joined #duraspace
[21:14] * mhwood (firstname.lastname@example.org) Quit (Remote host closed the connection)
[21:39] * tdonohue (~email@example.com) has left #duraspace
[23:41] * awoods_ (~firstname.lastname@example.org) has joined #duraspace
[23:44] * awoods (~email@example.com) Quit (Ping timeout: 255 seconds)
[23:58] * awoods_ is now known as awoods
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.