Timestamps are in GMT/BST.
[0:23] * edInCo (~edInCo@seta.coalliance.org) Quit (Quit: Leaving.)
[0:35] * eddies (~eddies@c-24-118-24-43.hsd1.mn.comcast.net) has joined #duraspace
[0:35] * eddies (~eddies@c-24-118-24-43.hsd1.mn.comcast.net) Quit (Changing host)
[0:35] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[1:35] * edInCo (~edInCo@174.51.171.25) has joined #duraspace
[5:12] * PeterDie_ (~peterdiet@128.146.173.70) has joined #duraspace
[5:14] * PeterDietz (~peterdiet@128.146.173.70) Quit (Ping timeout: 246 seconds)
[6:42] * edInCo (~edInCo@174.51.171.25) Quit (Quit: Leaving.)
[6:51] -moorcock.freenode.net- *** Looking up your hostname...
[6:51] -moorcock.freenode.net- *** Checking Ident
[6:51] -moorcock.freenode.net- *** Found your hostname
[6:51] -moorcock.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:02] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:18] * edInCo (~edInCo@c-174-51-171-25.hsd1.co.comcast.net) has joined #duraspace
[12:57] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:09] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[14:53] * eddies (~eddies@75-149-149-10-Minnesota.hfc.comcastbusiness.net) has joined #duraspace
[14:53] * eddies (~eddies@75-149-149-10-Minnesota.hfc.comcastbusiness.net) Quit (Changing host)
[14:53] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[15:35] * hilton (~chatzilla@197.79.8.131) has joined #duraspace
[15:37] * hilton (~chatzilla@197.79.8.131) Quit (Client Quit)
[16:34] * edInCo (~edInCo@c-174-51-171-25.hsd1.co.comcast.net) Quit (Quit: Leaving.)
[17:06] * edInCo (~edInCo@seta.coalliance.org) has joined #duraspace
[19:15] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:44] * l_a_p (~chatzilla@93-63-19-177.ip25.fastwebnet.it) has joined #duraspace
[19:53] * kstamatis (6df285ec@gateway/web/freenode/ip.109.242.133.236) has joined #duraspace
[19:58] * pdurbin (~pdurbin@server1.greptilian.com) has joined #duraspace
[19:59] * bollini (~chatzilla@host206-210-dynamic.37-79-r.retail.telecomitalia.it) has joined #duraspace
[20:00] <tdonohue> Hi all. Welcome to the weekly DSpace Developers Mtg (back from OR13!). Our agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-17
[20:00] <kompewter> [ DevMtg 2013-07-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-17
[20:01] <tdonohue> we'll kick things off with a few Pull Request reviews (as we have skipped these the last few weeks)
[20:01] <tdonohue> here's the pulls, ordered oldest first: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <tdonohue> we left off at #192: https://github.com/DSpace/DSpace/pull/192 (related to DS-1164)
[20:01] <kompewter> [ DS-1164 ensuring that UTF-8 encoding gets enforced by bram-atmire · Pull Request #192 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/192
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1164 ] - [#DS-1164] XML InputStream is created using a platform-specific character encoding - DuraSpace JIRA
[20:02] <tdonohue> hmm...this seems like a tiny obvious fix we should just merge
[20:02] <mhwood> I agree with Bram: simple and straightforward.
[20:03] <helix84> IIRC, there were many more instances of this call
[20:03] <helix84> yep, there are 48
[20:04] <tdonohue> Oh, I see... yea, that's noted in the comments of DS-1164
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1164 ] - [#DS-1164] XML InputStream is created using a platform-specific character encoding - DuraSpace JIRA
[20:04] <mhwood> Ah, now I see the ticket discussion. Maybe this is not complete yet?
[20:04] <tdonohue> yea, this sounds like we should just note to Bram that the direction seems good, but the pull needs more work
[20:05] <helix84> I don't know, it needs someone who understands what's going on there :)
[20:05] <helix84> I don't even know how to test it
[20:05] <mhwood> Hmmm. Shouldn't an XML document *say* what its encoding is? <?xml encoding='UTF8'?>
[20:06] <tdonohue> I'll add a comment to the PR for Bram and link to these logs. I agree, not sure how to test it, etc.
[20:07] <helix84> "Because each XML entity not accompanied by external encoding information and not in UTF-8 or UTF-16 encoding must begin with an XML encoding declaration..."
[20:08] <tdonohue> ok, comment added to PR #192
[20:09] <tdonohue> next PR is #195: https://github.com/DSpace/DSpace/pull/195 (DS-1089)
[20:09] <kompewter> [ DS-1089 Feedback form breaks when hostname is short by helix84 · Pull Request #195 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/195
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1089 ] - [#DS-1089] Feedback form breaks when hostname is short - DuraSpace JIRA
[20:10] * pdurbin hopes we get to https://github.com/DSpace/DSpace/pull/224 or https://github.com/DSpace/DSpace/pull/229 (SWORD stuff) :)
[20:10] <kompewter> [ DS-1554 redefine hardcoded SWORD upload dir (3.x) by helix84 · Pull Request #224 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/224
[20:10] <kompewter> [ Updated SWORDv2 module by richard-jones · Pull Request #229 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/229
[20:11] <mhwood> Looks like maybe agreement that this needs more thought?
[20:11] <helix84> i completely forgot about this one
[20:11] <helix84> i'll have to test it again
[20:11] <tdonohue> PR #195 definitely has a lot of discussion going on..
[20:11] <tdonohue> ok, so, helix84 do you want to take lead on 195 then? Just not sure where else to leave this one
[20:13] <helix84> I hope I'll have time for that, but if someone wants to take initiative, even better (mark? wink wink)
[20:13] <tdonohue> pdurbin: since you are here & interested, we can likely take a moment to look at those two SWORD PRs (once we are done with this one). one is tiny, the other one we are "working on"
[20:13] <mhwood> I'll look into it further, yes, since I've been making noise about it.
[20:14] <pdurbin> tdonohue: awesome. thanks!
[20:14] <tdonohue> thanks mhwood.
[20:14] <helix84> mhwood: if you know how to write tests for that, that would help
[20:14] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:14] <tdonohue> Ok, by pdurbin's request, let's glance at PR #224 : https://github.com/DSpace/DSpace/pull/224
[20:14] <kompewter> [ DS-1554 redefine hardcoded SWORD upload dir (3.x) by helix84 · Pull Request #224 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/224
[20:14] <mhwood> Not sure I know how to write tests at all :-), but will see. Making a note of that....
[20:15] <helix84> Ds-1554 _this_ one should be straightforward :)
[20:15] <pdurbin> tdonohue: I think I'm the only one using https://github.com/swordapp/JavaServer2.0 ... at least according to http://www.mail-archive.com/sword-app-tech@lists.sourceforge.net/msg00310.html
[20:15] <kompewter> [ swordapp/JavaServer2.0 · GitHub ] - https://github.com/swordapp/JavaServer2.0
[20:15] <kompewter> [ Re: [sword-app-tech] JavaServer2.0 and JavaClient2.0 from https://github.com/swordapp ] - http://www.mail-archive.com/sword-app-tech@lists.sourceforge.net/msg00310.html
[20:16] <tdonohue> PR #224 / DS-1554 to me seems like a rather obvious fix. That config shouldn't be hardcoded
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1554 ] - [#DS-1554] swordv2-server.cfg not updated during build process - DuraSpace JIRA
[20:17] <mhwood> I agree.
[20:17] <tdonohue> and it also seems like something to fix both on dspace-3.x branch and master branch
[20:17] <helix84> push the button and i'll backport it
[20:17] <tdonohue> thanks helix84!
[20:17] <pdurbin> https://github.com/DSpace/DSpace/pull/229 is the one that affects the https://github.com/swordapp/JavaServer2.0 library I'm using (it would seem) ... I'm interested in anything that pushes along development of the upstream library
[20:17] <kompewter> [ Updated SWORDv2 module by richard-jones · Pull Request #229 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/229
[20:17] <kompewter> [ swordapp/JavaServer2.0 · GitHub ] - https://github.com/swordapp/JavaServer2.0
[20:18] <tdonohue> was getting to that one next, pdurbin :)
[20:18] <pdurbin> :)
[20:18] <helix84> pdurbin: for the record I'm not ignoring you, I just don't know what that's about ;)
[20:19] <tdonohue> Regarding Pull #229, it's "unmergeable" at this time. I've talked to Richard Jones recently (both last week at OR13 conference, and at an IRC meeting like this a few weeks back)
[20:19] <pdurbin> unmergeable? d'oh!
[20:19] <hpottinger> I think PeterDie_ was going to chip in with some Git "magic"
[20:19] <tdonohue> Essentially, Richard Jones has requested some help "refactoring" (rebasing) Pull #229... currently it accidentally reverts several major changes in the DSpace codebase (as he built the PR based on DSpace 1.8.x)
[20:19] <PeterDie_> ooh, hi
[20:20] <mhwood> #224 merged. It's on 3_x already so it needs to be *forward*-ported.
[20:20] <hpottinger> Hi, Peter, something about subtree merges, and a whole bunch of hand waving :-)
[20:20] <helix84> mhwood: thanks, I'm on it
[20:20] <tdonohue> The plan (as far as I'm aware) is that PR #229 should be *fixed* before Dspace 4.0 release (later this year). But, it needs some "love" still before we can let it be merged (otherwise it's gonna break a lot of our code)
[20:21] <PeterDie_> yeah. To simplify development, Richard copy/pasted swordv2 into a new repository, so it just sort of starts and its a big diff.
[20:21] <pdurbin> tdonohue: hmm, but the upstream SWORD library... maybe it could see some development, right? ... shouldn't affect your code
[20:21] <PeterDie_> Its not un-mergeable. It just ended up as a giant diff. It has some issues that should get cleaned up, since he did it off of 1.8.x, and he's trying to commit it to 4.x/4.snapshot
[20:22] <tdonohue> PeterDie_ : Just to clarify...are you planning to help Richard with cleaning it up?
[20:22] <tdonohue> PeterDie_ : I didn't mean "unmergeable" in that it cannot be merged... I actually meant "unmergeable" in that it *should not* be merged as-is, as it will break our codebase :)
[20:22] <PeterDie_> I watched the presentation last week on swordv2-dspace, and I was able to follow along enough to know that if someone wanted to use sword2 with DSpace, Richard Jones probably knew the most about it. So I can't quite review the sword-worthyness of the commit (i.e. does this meet the swordv2 spec)
[20:23] <PeterDie_> But I can help clean up the git history, and try to reject things that are unintended consequences. So yes, I will work on this PR to get it in.
[20:23] <tdonohue> I don't think Richard is asking for someone to review the "sword-worthyness". He just needs help with git cleanup. :)
[20:23] <helix84> I thought richard already forward-ported this. I'll have to re-check.
[20:23] <tdonohue> thanks PeterDie_! (aka PeterDietz)
[20:24] <pdurbin> tdonohue: right, Richard being the SWORD spec lead and all :)
[20:24] <tdonohue> helix84: no, not that I'm aware. Richard Jones was still asking for help on it last week at OR13... I told him we'd get him help (likely either Peter or I)
[20:25] <PeterDie_> I did an attempt at some git magic, in which I expanded his two commit change, and pulled in something from nyo. The result is at: https://github.com/peterdietz/DSpace/commits/swordv2-update
[20:25] <kompewter> [ Commits · peterdietz/DSpace · GitHub ] - https://github.com/peterdietz/DSpace/commits/swordv2-update
[20:25] <helix84> ok, my bad (memory check error)
[20:25] <PeterDie_> I don't know if its any better
[20:25] <tdonohue> pdurbin: yep, Richard is the SWORD lead. He's also a (long-time) DSpace Committer. So, he's in both worlds
[20:26] <tdonohue> Ok, likely time to move along to actual meeting topics :) I think we've done enough of the PRs for today
[20:26] <pdurbin> tdonohue: thanks again!
[20:26] <tdonohue> no prob, pdurbin
[20:27] <tdonohue> So, first off...just wanted to review OR13 (and our Developers Meeting) for any "takeaways" / action items
[20:28] <tdonohue> Our OR13 Devel Mtg notes are at https://docs.google.com/document/d/1QzrmHDvpJlpsVo6e8tJvWk2rXZm1p_F3TaUcEKIeODU/edit
[20:28] <kompewter> [ DSpace Developers/ DCAT Meeting OR2013 - Notes - Google Drive ] - https://docs.google.com/document/d/1QzrmHDvpJlpsVo6e8tJvWk2rXZm1p_F3TaUcEKIeODU/edit
[20:28] <PeterDie_> REST is still unfinished business
[20:29] <hpottinger> Though, I feel a lot better about where REST is right now
[20:29] <tdonohue> yea, REST is still "unfinished" but it seemed (to me at least) that we made a little headway on possible directions.... namely the idea to work towards a spec and then see what "fits" best (something we already have? something quick to build?)
[20:30] <PeterDie_> I've found the discussion on metadata actually very interesting. (I missed the hierarchical metadata talk due to time conflict with sword2). i.e. I would love some type of Person/Author registry within DSpace, and the heirarchical metadata. Being able to know a person as person:1234, and then to lookup person[1234] and get fullName or get their orcid or linkedin, etc depending on what has been linked
[20:30] <tdonohue> So, I hope the REST Team still keeps pushing at that... It'd be great to have *something* (even basic/beta-level) in 4.0 if it's possible, but I understand if we don't have enough time.
[20:31] <helix84> PeterDie_: I wouldn't call that hierarchical metadata. That is addressed partially by metadata for all (metadata for other objects than items) and relations between objects (which we don't have, but see dspace-cris)
[20:32] <tdonohue> from my understanding (talking to Val this week) DCAT felt they got a lot of great feedback on the improved metadata support initiative, and they seem energized to keep moving it forward / find ways to make small steps in that direction
[20:33] <mhwood> Yay!
[20:33] <helix84> good to hear that, I was afraid the feedback might have been discouraging
[20:33] <PeterDie_> I'm tempted to propose putting in one of the existing API's into 4.0, and then whatever we implement in the future (i.e. Jersey), can honor the uri endpoints (i.e. /collection/1234, /community/12, ...) and it can add its own /author/Albert+Einstein
[20:33] <tdonohue> so, it may be that we'll want to find a time or meeting (in coming weeks or so) to talk more with DCAT members around perceived next steps, and see how we can get more involved
[20:34] <helix84> PeterDie_: I'd support that
[20:34] <mhwood> PeterDie_++. We need a decision more than we need immediate perfection.
[20:34] <tdonohue> PeterDie_: I'm completely OK with that, as long as there's some general agreement (just even amongst the "REST Team") that the URI endpoints seem "good enough" for a start
[20:35] <hpottinger> I've got a list of features I'd like to see make it into 4.0, which I expanded a bit during the discussion at the OR13 developers meeting (so I have names of people who chimed in about certain features), should I just copy/paste that to the Dev Meeting notes?
[20:35] <tdonohue> sounds like a "general consensus" here that it sounds good, as long as REST Team gives it their "initial blessing" :)
[20:35] <helix84> I just wanted to note that I percieve those two discussions as rather independent. The DCAT discussion is about standardization without changing the current flat "schema". metadata for all and dspace-cris is much more pioneering work.
[20:36] <helix84> hpottinger: please, do. i actually wanted to ask about such list.
[20:36] <tdonohue> hpottinger: feel free to copy into Dev Mtg notes, or just link Dev Mtg notes over to our 4.0 Release Notes page -- and add them there. Eventually possible features should get over to 4.0 release notes as well
[20:38] <hpottinger> There's one piece of dspace-cris I think would be immediately useful for DSpace, the integration with publisher metadata APIs to pull in existing metadata, which bollini demonstrated, looked slick, and frankly, my repository managers want that like yesterday
[20:38] <mhwood> Yes, cleanup of our "dc" namespace, metadata for all, and enriching the metadata format support can proceed separately.
[20:39] <hpottinger> Hmm... looking at these notes, they're a bit sketchy.
[20:39] <bollini> hpottinger: the integration with publisher metadata APIs is not actually part of dspace-cris... we have an "old" pull request that is just for dspace. DSpace-CRIS will help for further improvements, the automatic scanning, etc.
[20:40] <hpottinger> bollini: have a PR number for me?
[20:40] <helix84> i can't seem to find it, either: https://github.com/DSpace/DSpace/pulls/abollini
[20:40] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls/abollini
[20:41] <bollini> https://github.com/DSpace/DSpace/pull/78
[20:41] <kompewter> [ DS-1252 Initial contribution: (JSP)UI Import from bibliographics database/formats by abollini · Pull Request #78 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/78
[20:41] * helix84 needs glasses
[20:41] <tdonohue> I think we all should look closer at dspace-cris (as a group), and start to think about whether there are parts worth adding into a future version of DSpace. I know dspace-cris is already moving in directions that discussions in the USA around the "SHARE" proposal (also mentioned at OR13) may eventually go.
[20:41] <hpottinger> specific to the metadata discussion, I have down that tdonohue and Richard Jones said they'd work together on building a mapping tool for Phase One of the DCAT metadata changes
[20:42] <bollini> hpottinger: it was related to the "first" version of the importer with a basic not interactive UI for batch import
[20:42] <tdonohue> hpottinger: yea, I vaguely remember volunteering for that ;) I haven't had a chance to chat with the DCAT folks yet about what that means, but plan to.
[20:43] <helix84> bollini: how does this BibTeX import relate to the BTE importer?
[20:43] <bollini> hpottinger: the version that I have presented at OR is a very big refactoring and I'm not sure that I will be able to contribute it for 4.0
[20:43] <hpottinger> bollini: how can I help?
[20:43] <helix84> bollini: I know you reviewed the EKT work. Is this completely separate?
[20:44] <bollini> helix84: yes it is...
[20:46] <helix84> I also see an old library being used there - javabib 20040801 - which is not necessarily a problem, but it raises a flag (we already have another importer, do we want to use another library that is potentially unmaintained?)
[20:47] <tdonohue> ok, out of OR13, I know we also didn't have a chance to revisit the ideas around "empowering individuals / small teams to work more rapidly". So that may be a topic to touch on in a future meeting, though I think we already have a good example of the "REST Team" being such a small, trusted team
[20:47] <bollini> helix84: we have used a very simple bibtex parsing library to take care of its, honestly I don't know about how it compares to the EKT importer (I haven't reviewed this specific contribution)
[20:48] <helix84> no problem, my question pertains only to one of the imported types, the rest is still very interesting
[20:48] <tdonohue> and I'd encourage other "small teams" to form as we need them to tackle new features / brainstorm ideas. Not everything needs to flow through the Committers, but obviously it'd be good to have (a few) Committers involved in such teams. I'll leave it at that for now
[20:49] <bollini> helix84: right, anyway I'm also think that we should rely on a single library as far as possible
[20:49] <tdonohue> So...noticing we are running short on time, and I think we really need to make sure to talk about the pending 3.2 release today
[20:49] <hpottinger> honestly, tdonohue, I think if any team wants to self-form, and do their thing, bringing their work to the group for approval later... that's just an extension of how we already work
[20:50] <mhwood> Hopefully they will bring their work out sooner rather than later....
[20:50] <helix84> bollini: apart from that, it needs some tiny changes as joao pointed out
[20:50] <tdonohue> +1 hpottinger : I agree. Just wanted it to "be known" that I & DuraSpace support this idea. And I also agree with mhwood that these "small teams" should try and still be transparent in their work, etc.
[20:51] <tdonohue> So, I hate to jump the discussion quickly away from OR13 outcomes -- which I'm sure we could continue discussing for some time. But, it might be good to switch over to 3.2 for a bit...just to try and get it "scheduled", etc.
[20:51] <mhwood> What we need is that it be seen as normal that teams should form around projects where appropriate, as they see the need, and that it's normal to show work in progress to get early feedback.
[20:51] <mhwood> Yes, 3.2.
[20:52] <hpottinger> I have on my calendar that we will put out 3.2 on Friday, I also have promised to help someone move on Friday afternoon, so I'm hoping, if I am going to pull the lever on 3.2, that we're going to put it out in the morning
[20:52] <hpottinger> though, someone else is welcome to put out the release, it's fun :-)
[20:53] <tdonohue> hpottinger: Fri morning is fine with me as well. We may want to have a "backup" in case things take longer than expected and you have to depart before they are finished (doubtful, but just to "be safe")
[20:53] <tdonohue> I'd be willing to help draft up the announcement to the community about the release.
[20:54] <tdonohue> Oh, and we also need to do the "backport" releases (1.8.3 and 1.7.3). I've cleaned up both branches, so they *should be* releaseable (I did some basic testing including a "dry run release" on each). Just a matter of backporting the commit and releasing those as well
[20:55] <tdonohue> Anyone else what to join the release fun with hpottinger & I on friday? I'm sure we'll be just hanging out in #dspace working on it
[20:56] <hpottinger> Oh, yeah, I *do* need to finish those backports
[20:56] <helix84> tdonohue: I'd really appreciate getting the OAI fix in also
[20:57] <tdonohue> are they possible to finish / have ready by Friday? Just want to be sure that this is still all doable by then. If it isn't, we don't need to rush it...but we really should get this release(s) out either this week or next
[20:57] <helix84> tdonohue: that was the one which also brought one small new feature with it
[20:57] <helix84> it turned out hard to decouple them
[20:57] <tdonohue> helix84: OAI fix? gonna need to refresh my memory more..have some vague recollections here. Have a PR# or JIRA ticket?
[20:58] <helix84> https://github.com/DSpace/DSpace/pull/219
[20:58] <kompewter> [ DS-1479 : Oai with custom descriptions by lyncodev · Pull Request #219 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/219
[20:59] <tdonohue> and remember, I'm not the "official decider" :) If it's something we need approved, we can try and discuss it quickly now to approve it.
[20:59] <helix84> well, the release team is here
[21:00] <tdonohue> Oh, yea, I recall PR #219 now. I remember my only concern was that it added a *new* config setting (to oai.cfg). But, Joao clarified that things will still work fine if that config setting is missing...so, it's not *required* to add that new config.
[21:00] <helix84> actually the RT doesn't officially decide on release branches
[21:00] <helix84> can we just have a vote?
[21:01] <tdonohue> and it fixes DS-1479
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1479 ] - [#DS-1479] In OAI-PMH "Identify" response, the <description> is no longer configurable - DuraSpace JIRA
[21:01] <tdonohue> yea, we can just have a vote. That's what I was suggesting / implying. We could vote it in now, as long as there's no objections
[21:02] <helix84> there's a dspace-commit thread about that
[21:02] <helix84> me, hpottinger, tdonohue already agreed to it after clarifications
[21:02] <helix84> no objections so far
[21:02] <tdonohue> It is in a "somewhat grey" area between bug fix & improvement, as it adds a new config setting (which we normally don't do in "x.2" releases). But, since the config setting isn't required, I think it sounds fine to me (assuming no one else objects)
[21:03] <mhwood> Okay by me.
[21:03] <bollini> if I remember correctly (I don't use xoai yet) the released version just not work (at all or for many use cases) so it should be just fine to release an upgrade. The really upgrade here is not the dspace pull request but the xoai version upgrade
[21:03] <mhwood> +1
[21:03] <hpottinger> +1
[21:03] <tdonohue> +1 too
[21:04] <helix84> +1, for the record
[21:04] <helix84> bollini: you're right
[21:04] <bollini> so... +1 too :-)
[21:05] <tdonohue> sounds like consensus. So, we just need someone to merge it into master & dspace-3.x branches
[21:05] <helix84> I'll do it
[21:05] <tdonohue> thanks helix84
[21:06] <helix84> there's also one more oai bug fix, which seems without problems
[21:06] * hpottinger notes that everyone managed to duck out of volunteering to back him up on Friday...
[21:07] <helix84> hpottinger: we're getting really good at ducking ;)
[21:07] <tdonohue> So, regarding 3.2 & all these last minute things: Do we all think Fri is still doable? do we need to rethink that / aim more for early next week? Any other volunteers to help for hpottinger & I?
[21:07] <helix84> the OAI changes are going in today, no delays by me!
[21:08] <bollini> I'm just not able to help for 3.2 not this Fri nor the next week...
[21:08] <mhwood> Argh, sorry, I'm out of town tomorrow and Friday.
[21:09] <hpottinger> I have the backport ready for 1.7 and 1.8, just need to finish up, can try to do tonight, but, yeah, the time line might be too short, if we want to do any testing.
[21:10] <tdonohue> hmm... so from the sounds of it, it's just hpottinger & I. hpottinger, what do you think? I'm not sure I can help with "backporting" to 1.7.x/1.8.x. But, I can provide support in the release process & also write the announcement
[21:10] <tdonohue> ok..I hear some hesitation in hpottinger's words. Makes me suspect that early next week would be better
[21:12] <tdonohue> next week, I'd be available to help Tues or Weds. Mon afternoon could work too. Mon morning is too packed for me
[21:12] <hpottinger> how about we declare Friday as the last day that any of the release branches can change, and then we test on Monday?
[21:12] <tdonohue> +1 hpottinger
[21:13] <tdonohue> then we can aim to release either Mon afternoon or Tues, perhaps? Send out the announcements likely on Tues (once all has propagated)?
[21:14] <mhwood> Sounds okay but would not like to see it slip further.
[21:14] <hpottinger> Tuesday afternoon looks better on my schedule
[21:15] <mhwood> I must go. Thanks, all!
[21:15] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:15] <tdonohue> I agree, I don't want this to slip further. Tues afternoon is fine, hpottinger, if that's what works best for you
[21:16] <tdonohue> I can be available Tues for support and make sure we have announcement ready to go
[21:16] <hpottinger> show starts in #dspace at 2pm CDT (7 UTC, I think, if my math is correct)
[21:17] <hpottinger> actually, that's 19 UTC, isn't it?
[21:17] <tdonohue> 2pm CDT = 3pm EDT = 19:00 UTC :)
[21:18] <tdonohue> so, yes...let's start the show Tues, 7/23 @ 19:00 UTC in #dspace . Anyone who can join us / help out, please feel free! Extra help/support would be appreciated
[21:19] <hpottinger> https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[21:19] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[21:19] <tdonohue> I think that's it for today, and we're well over time here. So, I'm not going to call any other agenda items. We'll leave everything else for next week
[21:19] <bollini> as we are already overtime, I want just try to fastly get back to the 4.0 timelines... at CINECA we are planning about which contributions are we able to share for 4.0 and it is essentially for us to know if the feature freeze can be postponed to the end of October (for 3.0 was August), the release should go at the end of November or December. Is it reasonable?
[21:19] <tdonohue> and hpottinger, if you need extra support/help/eyes along the way towards 3.2/1.8.3/1.7.3, please ask on dspace-commit
[21:20] <helix84> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130723T19
[21:20] <kompewter> [ Event Time Announcer ] - http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130723T19
[21:20] <hpottinger> https://wiki.duraspace.org/display/DSPACE/Release+Procedure#ReleaseProcedure-Prerequisites
[21:20] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure#ReleaseProcedure-Prerequisites
[21:21] <helix84> I'm not on RT, just my 2c: we have relatively few new features so far, so IMHO it makes sense to wait for larger features
[21:21] <hpottinger> bollini, we can discuss timelines on the dspace-release mail list if you wish, the last few times we've just looked at the timeline front he previous year and adjusted it
[21:22] <bollini> ok, I will send an email to the dspace-release mail list
[21:23] <bollini> I really think that we should formalize a 4.0 timelines and not rely on the past 3.0
[21:23] <hpottinger> and bollini, if you want to just pick your preferred timelines and use that as a place to start discussion, I don't think anyone would object
[21:24] <tdonohue> I will mention that with 1.7.0, we did have a later "feature freeze" (Oct 22). It worked out, but it caused the final release to not happen until Dec 17 (which was just before Christmas holiday). I recall there being some complaints back then about having a release so late in December https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.7.0+Notes
[21:24] <kompewter> [ DSpace Release 1.7.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.7.0+Notes
[21:24] <tdonohue> But, I agree, probably best to bring this discussion to the 'dspace-release' mailing list
[21:24] <bollini> ok good. Keep in touch on the mailing list
[21:24] <hpottinger> speaking of dspace-release mail list, it's an open mail list, so sign up if you want to participate in the nitty-gritty discussion
[21:25] <tdonohue> +1 hpottinger : yes, all please do join dspace-release (if interested). It's mostly "inactive" until we get to releases when it "comes alive" with discussions :)
[21:26] <bollini> I must go. bye!
[21:26] * bollini (~chatzilla@host206-210-dynamic.37-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212])
[21:26] <hpottinger> https://lists.sourceforge.net/lists/listinfo/dspace-release
[21:26] <kompewter> [ Dspace-release Info Page ] - https://lists.sourceforge.net/lists/listinfo/dspace-release
[21:27] <tdonohue> meeting is adjourned (obviously). I'm still around for a bit if there's "unofficial" things to talk about though...
[21:28] <helix84> just noting that both OAI fixes are on both master and dspace-3_x
[21:29] <pdurbin> I'm just happy we talked about SWORD :)
[21:30] * l_a_p (~chatzilla@93-63-19-177.ip25.fastwebnet.it) Quit (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130618035212])
[21:31] <helix84> pdurbin: :)
[21:31] <helix84> pdurbin: if you want to put your git-fu to test, feel free to forward port-it to master and submit a PR
[21:31] <tdonohue> helix84: thanks!
[21:31] <helix84> pdurbin: I believe nothing else stands in its way
[21:33] <helix84> tdonohue: I just noticed a small issue at Bamboo
[21:33] <tdonohue> helix84: quick question around PR # 224 (which you wrote but mhwood merged). Does this fix DS-1554? It looks like there's another PR (#225) linked to Ds-1554 as well... not sure if we need to split this ticket to detail what fix is in 3.2 and what may go in 4.0?
[21:33] <helix84> tdonohue: if you hover over a commit, the tooltip says Why: %B
[21:33] <kompewter> [ https://jira.duraspace.org/browse/DS-1554 ] - [#DS-1554] swordv2-server.cfg not updated during build process - DuraSpace JIRA
[21:34] <tdonohue> helix84: yea, aware of that Bamboo bug. It's a bug in Bamboo itself, and will be fixed when we next upgrade (actually planned for this week or next, depending on when I find time)
[21:35] <helix84> tdonohue: oh, I forgot about that one. 225 also takes care of the case when the config property is not defined.
[21:35] <helix84> tdonohue: thanks for noticing. I'll use the 225 fix instead.
[21:36] <pdurbin> helix84: I guess I'm still curious about "In order to use this module, we also need to push a new version of the Java Server library for SWORDv2 into the central maven repo" ... is there a commit somewhere for that new version of the common library? Last commit to the common library was 5 months ago but the dspace pull 229 is only a month old
[21:37] <tdonohue> ok, helix84. Just checking. once you've cleaned it up, just ensure Ds-1554 gets closed/marked appropriately :)
[21:37] <helix84> pdurbin: it would be best to ask richard directly
[21:37] <pdurbin> helix84: sure. makes sense. maybe I'll ask on the sword mailing list
[21:47] * kstamatis (6df285ec@gateway/web/freenode/ip.109.242.133.236) has left #duraspace
[21:48] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:49] <helix84> all done now, PR 225 is on master
[21:49] <helix84> good night
[22:00] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[22:01] * PeterDie_ (~peterdiet@128.146.173.70) Quit (Ping timeout: 245 seconds)
[22:03] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:25] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[22:31] * edInCo (~edInCo@seta.coalliance.org) Quit (Quit: Leaving.)
[23:04] * edInCo (~edInCo@174.51.171.25) has joined #duraspace
[23:15] * PeterDietz (~peterdiet@d60-65-80-138.col.wideopenwest.com) has joined #duraspace
[23:47] * PeterDietz (~peterdiet@d60-65-80-138.col.wideopenwest.com) Quit (Remote host closed the connection)
[23:47] * PeterDietz (~peterdiet@d60-65-80-138.col.wideopenwest.com) has joined #duraspace
[23:52] * PeterDietz (~peterdiet@d60-65-80-138.col.wideopenwest.com) Quit (Ping timeout: 268 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.