Timestamps are in GMT/BST.
[0:02] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[0:13] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[0:16] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 260 seconds)
[0:25] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) has joined #duraspace
[0:48] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[2:13] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[2:19] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 276 seconds)
[3:45] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[3:53] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 260 seconds)
[3:57] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[4:11] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 276 seconds)
[4:14] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[4:19] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 240 seconds)
[6:16] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[6:20] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[6:46] -sendak.freenode.net- *** Looking up your hostname...
[6:46] -sendak.freenode.net- *** Checking Ident
[6:46] -sendak.freenode.net- *** Found your hostname
[6:47] -sendak.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@webster.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
[7:56] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[11:16] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:32] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:08] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[14:15] * peterdietz (uid52203@gateway/web/irccloud.com/x-ucpildeikmhwrqom) has joined #duraspace
[14:32] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[14:38] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[14:57] * tdonohue reminds folks the DSpace Dev Mtg starts shortly here: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-04-20
[14:58] * pmarrone (~pmarrone@proxy3.psi.unc.edu.ar) has joined #duraspace
[15:00] <hpottinger> RC1 *tomorrow* woohoo
[15:01] <tdonohue> Hello all, welcome. The DSpace DevMtg starts now. Agenda was pasted above
[15:01] <tdonohue> Jumping right in today... 6.0 is moving along now (thanks to everyone for all the hard work!). Testathon begins on Monday. So, today is all about trying to do the final push to RC1 and Testathon
[15:03] <tdonohue> First comes first... RC1. The goal is to have RC1 cut either tomorrow or Fri (i.e. before the weekend, so we can have it ready to go for Testathon on Monday)
[15:03] <tdonohue> The only thing (I'm aware of) that stands in the way of RC1 is DS-3125. (We have some other minor outstanding known bugs, but none absolutely *have* to be resolved prior to RC1 or Testathon
[15:03] <kompewter> [ https://jira.duraspace.org/browse/DS-3125 ] - [DS-3125] Submitters cannot delete bistreams of workspaceitems - DuraSpace JIRA
[15:04] <tdonohue> Has a PR waiting for review/testing: DSPR#1352
[15:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/1352 ] - [DS-3125] Submitters cannot delete bistreams of workspaceitems by KevinVdV
[15:05] <tdonohue> Could someone help us get this tested? I've checked the code, and it passes a review (all looks reasonable). But, probably needs a test run.
[15:06] <tdonohue> It does involve a new DB migration...but it looks reasonable to me. much more info in the PR itself
[15:06] <hpottinger> I'll give it a try
[15:06] <tdonohue> hpottinger: thanks. Do you think you will have time to tackle this later today (or early tomorrow)? Obviously it's high priority
[15:06] <hpottinger> tackling it right now
[15:07] <tdonohue> awesome. you rock, hpottinger!
[15:07] <hpottinger> it's why I have more than one monitor :-)
[15:08] <tdonohue> So, are there any other PRs / Tickets that *must* be in prior to our RC1? (Or anything folks would really *like* to get in but need a quick review?)
[15:08] <terry-b3> I am the only +1 for https://github.com/DSpace/DSpace/pull/1287, but it looks good
[15:09] <pbecker> I think it is simple to get https://github.com/DSpace/DSpace/pull/931 in.
[15:09] <kompewter> [ DS-2552: Makes configurable whether handles or DOIs should be displayed in JSPUI by pnbecker · Pull Request #931 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/931
[15:09] <pbecker> Would help users that mintes DOIs and use JSPUI.
[15:09] <pbecker> s/mintes/mints
[15:09] <kompewter> pbecker meant to say: Would help users that mints DOIs and use JSPUI.
[15:09] <pbecker> but as always: we need somone to test it running JSPUI. ;-)
[15:10] <tdonohue> taking these in order...thanks for the reminder on 1287, terry-b3. I agree that would be nice to get merged so it could get tested thoroughly in testathon. It sounds like 1287 just needs a quick code review +1 from someone else to get merged
[15:11] <tdonohue> I can try and give 1287 a code review post-meeting, if no one else beats me to it.
[15:11] <tdonohue> As for 931...looks like it already has a code review, and a few +1's. Is it waiting on a test? Have you tested it locally pbecker?
[15:12] <mhwood> peterdietz: are your concerns in 1287 addressed?
[15:12] <pbecker> I tested it before I rebased last. But if it is okay for you I retest it tomorrow morning and merge it myself.
[15:13] <tdonohue> mhwood: from my reading of 1287, peterdietz was just noting that PDFBox 2 doesn't necessarily "fix" our non-ASCII problems, which was the hope. It doesn't seem to point out any NEW issues though that PDFBox 2 has over v1
[15:13] <tdonohue> pbecker: that sounds like a good solution for 931. Give it a final test, then merge
[15:13] <pbecker> great, will do.
[15:13] <peterdietz> yeah. hi all. It looks like we'll still have the same issues. So, my issues are irrelevant
[15:13] <mhwood> Good enough for me, if it's good enough for you.
[15:14] <hpottinger> it sounds a bit like 1287 is ready now?
[15:14] <tdonohue> As noted by terry-b3 in 1287 though, it sounds like there are some minor improvements (see his last comment) in v2 versus v1 of PDFBox. But, it may not have solved all the issues we've seen yet
[15:14] <tdonohue> 1287 is ready pending another +1, in my opinion
[15:14] <terry-b3> My test set was limited, but I found at least one improvement.
[15:15] <peterdietz> yep. I'd say +1, it brings some improvements. Though the pdf citation stuff is likely to still not be fully suitable to all use cases
[15:15] <tdonohue> In any case, it sounds like v2 is an improvement over v1 of PDFBox...so we should get this in
[15:17] <terry-b3> I posted some code review suggestions in https://github.com/DSpace/DSpace/pull/1253 (documentation related). If those are addressed, this would be a nice feature to merge.
[15:17] <kompewter> [ DS-3009 Allow classpath definition of command line tools by rradillen · Pull Request #1253 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1253
[15:17] <terry-b3> Is there a better way to alert a developer than to use the conversation thread in the PR?
[15:18] <tdonohue> terry-b3: no, I tend to use GitHub for such messages. You could send an email as well if you wanted, but most devs will respond via GitHub (and it's much easier to add inline comments in GitHub)
[15:18] <tdonohue> 1253 seems like something we could fit in after RC1 if needed
[15:19] <terry-b3> I agree.
[15:19] <tdonohue> While it doesn't have a PR, I will note I've been working to resolve DS-3104. Unfortunately our logging got a little messed up in the move to ConfigurationService / Commons Config. I think I finally have a handle on the problem, just trying to track down a solution. Hope to have it fit in prior to RC1 as well
[15:19] <kompewter> [ https://jira.duraspace.org/browse/DS-3104 ] - [DS-3104] DSpace's command line interface has problems finding the log directory - DuraSpace JIRA
[15:20] <tdonohue> So, that's just a minor FYI
[15:21] <tdonohue> After this meeting ( in JIRA backlog hour), or later on...we could also do some reviews of other PRs flagged for 6.0 that might be "quick wins". It would be nice to get as many of these into RC1 as is reasonable (without destabilizing anything, obviously).
[15:21] <pbecker> tdonohue: ping me, if DS-3104 is ready to be tested.
[15:21] <kompewter> [ https://jira.duraspace.org/browse/DS-3104 ] - [DS-3104] DSpace's command line interface has problems finding the log directory - DuraSpace JIRA
[15:22] <tdonohue> pbecker: will do. I can reproduce the issue. Unfortunately, the problem seems to be Log4j is accidentally getting "loaded" prior to ConfigurationService (which causes the errors). I'm trying to find a way to ensure ConfigurationService loads fully *prior* to log4j
[15:22] <tdonohue> pbecker: hopefully will have something later today
[15:23] <tdonohue> Ok. Any other tickets/PRs folks want to talk about right now? Otherwise, we'll revisit this topic in JIRA Backlog (post-meeting).
[15:23] <pbecker> I'm out of office directly after this meeting (caused by daylight saving the meeting is one our later again).
[15:23] <pbecker> But I could test something tomorrow.
[15:23] <tdonohue> that's fine
[15:24] <mhwood> Long-term, I would like to see if we can just let log4j load when it is touched, and stop trying to control it the way we do now.
[15:25] <tdonohue> mhwood: we *could* do that...but it'd require either filtering log4j.properties, or having folks directly touch/config logging there, instead of any of the existing "log.*" settings in dspace.cfg and similar
[15:26] <tdonohue> mhwood: But, that would be possible. I've just been trying to see if we can avoid having to filter the log4j.properties with log directory location (as then it can load "dspace.dir" from configService). But, it then requires configService to load *first*
[15:27] <tdonohue> In any case, we can chat more on this post meeting...I'll be working on it then. I'd hate to dig too deep on this in this meeting
[15:27] <mhwood> Yes, later.
[15:27] <tdonohue> Ok, so we are nearing RC1. We have Testathon next week. Regarding Testathon, DCAT has kindly created some "Test Plans" (for JSPUI and XMLUI) and linked them up to https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Testathon+Page
[15:27] <kompewter> [ DSpace Release 6.0 Testathon Page - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Testathon+Page
[15:27] * pmarrone (~pmarrone@proxy3.psi.unc.edu.ar) has left #duraspace
[15:28] <tdonohue> (see bottom of that wiki page)
[15:28] * pmarrone (~pmarrone@proxy3.psi.unc.edu.ar) has joined #duraspace
[15:29] <tdonohue> We'll be encouraging folks to try and help us fully test both UIs by following the test plans, and finding features in those plans that haven't yet been tested by someone else.
[15:29] <tdonohue> This is mostly all just an FYI...but you are also more than welcome to review those test plans and help DCAT enhance them (I know the XMLUI is further along than JSPUI, but others are working on the JSPUI plan this week)
[15:30] <tdonohue> Back to our agenda...we have several "tasks" that need to be done between today and Monday. I was hoping to find some volunteers to help me out with them
[15:30] <pbecker> Last week I discovered something but I'm not sure if that is a bug or if I'm misusing DSpace. I tend to give the Group anonymous submitter rights to all collections in my testsystem to achieve that any user is able to submit. In DSpace 6 this doesn't seem to work anymore. Is there another way to ensure that every user (with an account) is able to submit to a collection?
[15:32] <tdonohue> pbecker: I wasn't aware that worked. It might be worth looking into, but I'm not sure DSpace should be meant to support anonymous deposit (i.e. I think that's perhaps unintended)
[15:32] <pbecker> It didn't allow anoymous submission.
[15:32] <pbecker> It only ensured that everyone with an account was able to submit to such a collection.
[15:33] <tdonohue> Oh, again that sounds unintended.
[15:33] <mhwood> I thought that not defining a submitters group at all meant that it was open, but I haven't tested that.
[15:34] <pbecker> That didn't worked at least in JSPUI. But I can retest it.
[15:34] <tdonohue> Usually, this is done by creating a custom Group...then changing your Authentication plugin to specify that group as the "Special Group" which everyone who can login should be added to. Then use that "Special Group" as the submitter group to all Collections
[15:34] <tdonohue> For example, using password auth, you'd set this: https://github.com/DSpace/DSpace/blob/master/dspace/config/modules/authentication-password.cfg#L20
[15:34] <kompewter> [ DSpace/authentication-password.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/modules/authentication-password.cfg#L20
[15:35] <tdonohue> So, that concept is supported, but not by adding "anonymous" as the submitter group
[15:35] <pbecker> mhwood, tdonohue: thanks. I'll test that in the next days.
[15:36] <tdonohue> Back to the agenda...here's what I believe needs to be completed between today and Monday (Testathon):
[15:36] <tdonohue> 1) Cut RC1 release
[15:36] <tdonohue> 2) Update demo.dspace.org for testathon
[15:37] <tdonohue> 3) Draft Monday reminder announcement to kickoff Testathon. Include info about the new test plans, etc
[15:38] <tdonohue> I *think* that's it (but let me know if I overlooked anything). I'd appreciate help from others, any volunteers to tackle one of these?
[15:38] <mhwood> I'll take (2).
[15:39] <pbecker> how long does it take to cut a release?
[15:39] <tdonohue> Thanks. Even just that alone makes things easier on me... I can always tackle #1 and #3 as needed (if no one else wants to try it out)
[15:39] <pbecker> Will it save time if I do it for the first time or will this cost more time than it helps?
[15:40] <tdonohue> pbecker: it usually doesn't take too long (1-2 hours). But, first time around, it can take longer...as you might have a lot of questions along the way.
[15:41] <tdonohue> The one issue with RC1 is that we are very time constrained here. It *must* be done before Monday...and it must happen *after* we get final PRs merged. So, I'm OK with cutting RC1, but then I really do need others to help get final PRs merged / ready to go.
[15:41] <mhwood> We are here to answer questions.
[15:41] <terry-b3> demo.dspace.org currently has a lot of garbage in it. I presume the content refresh will happen before the release.
[15:41] <pbecker> I'm not sure if it helps, but I could try to cut it Friday afternoon/evening (CEST).
[15:42] <pbecker> Something like 4pm-8pm UTC. But I'll definitely will need help.
[15:42] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Remote host closed the connection)
[15:42] <tdonohue> pbecker: we could do that. That might work out fine, considering you could hand it over to me on Friday if it becomes too difficult or you run into issues along the way
[15:43] <pbecker> great plan. Do I need some more accounts (maven central, sonatype or something)?
[15:43] <pbecker> Do I need to reactivate my PGP key?
[15:43] <tdonohue> All the prerequisites are listed in the https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[15:43] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[15:43] <terry-b3> Does demo.dspace.org provide an opportunity for any performance testing or does that not happen until folks install locally and test with their own data?
[15:43] <tdonohue> And yes, we do need to get you setup via Sonatype
[15:44] <pbecker> Fine. I'll take a look and talk to you tomorrow.
[15:44] <tdonohue> pbecker: I can work with you on the prerequisites prior to Friday. You should read them over and setup the accts you need, and I can log a ticket with Sonatype to get you proper permissions, etc
[15:44] <mhwood> https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[15:44] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[15:44] <mhwood> Oh, someone already found that.
[15:45] <tdonohue> terry-b3: I agree we probably should cleanup demo.dspace.org prior to testathon (especially the content on the site, which doesn't seem to be refreshing...not sure why)
[15:45] <mhwood> Something keeps going wrong with JSPUI there as well. Possibly related.
[15:46] <pbecker> mhwood: I fixed this last week.
[15:46] <pbecker> But it's only a work around.
[15:46] <pbecker> There was a PR I still have to review.
[15:46] <tdonohue> terry-b3: and unfortunately, demo.dspace.org doesn't provide us with good capabilities for performance/scalability testing. It's a small server, and will hit memory issues if banged on too hard. But, I'd encourage someone to setup a performance test elsewhere
[15:47] <hpottinger> pbecker: the release docs are good, and the regulars in IRC are all great help with release questions. I can make a point of being on when you're working on cutting the release, if you tell me when you need me here.
[15:48] <tdonohue> mhwood: when you go to update demo.dspace.org (presumably on Fri, though technically you could just update it based on "master" anytime this week), we might want to look at whether the AIP restore process (which is supposed to cleanup the server) is throwing errors. I can help as needed too
[15:48] <mhwood> Thanks tdonohue.
[15:49] <tdonohue> mhwood: and if you get a chance to look at this before Friday, honestly all the better...we could just run demo.dspace.org off of "master" during Testathon. It need not be off the official RC1 necessarily
[15:49] <pbecker> hpottinger: thanks. :-) I'll plan to do start on Friday around 4pm UTC.
[15:49] <mhwood> I will poke around and see what I find.
[15:49] <terry-b3> tdonohue, we are troubleshooting some AIP restore issues for our test servers. I do not yet heave enough info to file a bug report, but I expect that we may have one to file soon.
[15:49] <tdonohue> hpottinger: it sounds like pbecker would be doing this on Friday morning (for us)
[15:50] <terry-b3> If you all can identify an issue with the restore, ping me. We can see if the issues sound similar to what we are seeing.
[15:50] <mhwood> 1600 UTC is noon here in EDT.
[15:50] <tdonohue> terry-b3: yes, thanks. If there is an issue, it likely is recent. I recall testing AIP restore stuff post-Service API refactor (and it worked then)...but it's possible something since then has caused issues
[15:51] <mhwood> 1100 CDT.
[15:51] <tdonohue> OK, so it sounds like we have a plan for the coming days:
[15:51] * pbecker has to close the libray building on Friday evening => late shift.
[15:52] <tdonohue> 1) We all try and get in more of the PRs that are "ready" (especially the last blocker which hpottinger is testing)
[15:52] <tdonohue> 2) pbecker will cut RC1 on Friday (around 16UTC). May hand it over to someone else if needed or goes too long
[15:52] <tdonohue> 3) mhwood will update demo.dspace.org before Monday
[15:52] <tdonohue> 4) tdonohue will draft up the Testathon announcement to send out on Monday
[15:53] <tdonohue> That's it. Anything I'm forgetting?
[15:54] * tdonohue notes I'm going to try and get our various README / LICENSE files updated prior to RC1 as well... especially that THIRD_PARTY_LICENSES one that we need to update for new major releases
[15:54] <mhwood> That is a big help for the release builder.
[15:55] <tdonohue> It sounds like we have a plan then! Thanks everyone for being willing to help chip in on this final push to RC1 / Testathon
[15:56] <tdonohue> I'm noticing we are nearing the end of this meeting. Are there any other official topics folks would like to bring up in this meeting? (As mentioned, post-meeting, I'd like to do some PR reviews to see if we have other "quick wins" to merge prior to RC1...we can do that over in #dspace in a bit)
[15:58] <tdonohue> Ok, not hearing any other topics. In that case, I'm going to close up this meeting. I need a few minutes break (quick coffee refresh). Then we'll start PR review in #dspace
[15:58] <tdonohue> Thanks all!
[16:03] * pmarrone (~pmarrone@proxy3.psi.unc.edu.ar) has left #duraspace
[16:22] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:43] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[17:47] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[19:44] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[19:49] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 276 seconds)
[20:15] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
[20:49] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:18] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[21:47] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[22:32] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 250 seconds)
[23:09] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) has joined #duraspace
[23:25] * kshepher1 (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:25] * kshepherd (~kim@wireless-nat-21.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[23:40] * kshepher1 (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 244 seconds)
[23:45] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
[23:50] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 276 seconds)
[23:59] * Insanity_ (~Insanity@85.234.195.109.static.edpnet.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.