Timestamps are in GMT/BST.
[6:48] -barjavel.freenode.net- *** Looking up your hostname...
[6:48] -barjavel.freenode.net- *** Checking Ident
[6:48] -barjavel.freenode.net- *** Found your hostname
[6:48] -barjavel.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:49] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:49] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:56] * peterdietz (uid52203@gateway/web/irccloud.com/x-moxcygvokjlkkwaw) Quit (Quit: Connection closed for inactivity)
[8:00] -mquin- [Global Notice] On or around Friday, October 2nd we will be cleaning up the services database. Now's a good time to ensure you identify to services when connecting. Check out http://blog.freenode.net/2015/09/services-database-purge/
[8:23] * cknowles (uid98028@gateway/web/irccloud.com/x-ucueqlwstvzyhdju) has joined #duraspace
[12:42] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:15] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:33] * cknowles (uid98028@gateway/web/irccloud.com/x-ucueqlwstvzyhdju) Quit (Quit: Connection closed for inactivity)
[16:02] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) has joined #duraspace
[16:43] * cknowles (uid98028@gateway/web/irccloud.com/x-cjlcucsiyvgsuizu) has joined #duraspace
[16:51] * peterdietz (uid52203@gateway/web/irccloud.com/x-ocvssdqzsbsdwmbk) has joined #duraspace
[17:00] -mquin- [Global Notice] On or around Friday, October 2nd we will be cleaning up the services database. Now's a good time to ensure you identify to services when connecting. Check out http://blog.freenode.net/2015/09/services-database-purge/
[17:44] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[17:49] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Quit: Leaving, later taterz!)
[17:50] * hpottinger (~hpottinge@128.206.253.146) has joined #duraspace
[19:03] * cknowles (uid98028@gateway/web/irccloud.com/x-cjlcucsiyvgsuizu) Quit (Quit: Connection closed for inactivity)
[19:05] * terry-b (~chrome@71-212-24-25.tukw.qwest.net) has joined #duraspace
[19:13] * bram-atmire (~bram@94-225-37-203.access.telenet.be) has joined #duraspace
[19:25] * terry-b (~chrome@71-212-24-25.tukw.qwest.net) Quit (Remote host closed the connection)
[19:27] * terry-b (~chrome@71-212-24-25.tukw.qwest.net) has joined #duraspace
[19:48] * cknowles (uid98028@gateway/web/irccloud.com/x-pcjcvpfmpusjndyb) has joined #duraspace
[19:48] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[19:57] * KevinVdV (~KevinVdV@d54c5104d.access.telenet.be) has joined #duraspace
[19:57] * hpottinger (~hpottinge@128.206.253.146) Quit (Quit: Leaving, later taterz!)
[20:01] <tdonohue> Hi all, welcome to our weekly DSpace DevMtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-09-30
[20:01] <kompewter> [ DevMtg 2015-09-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-09-30
[20:02] <tdonohue> Today, as usual, our primary topics are the Service API refactor & DSpace 6.0. We'll start with the Service API
[20:02] <tdonohue> First off, I wanted to thank EVERYONE who has been working hard to make this refactor happen especially KevinVdV!, and everyone listed at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:02] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:03] <tdonohue> As far as I see, our "refactor" is essentially COMPLETE. Though we still have been finding (and fixing) some minor bugs / making improvements.
[20:04] <tdonohue> But, EVERYTHING compiles and all our unit / integration tests succeed...plus UIs seem to work (at least from basic tests...we still need to dig into testing every single feature)
[20:06] <tdonohue> That said, we have three PRs that are still open against this "feature branch" (mostly minor bug fixes / improvements)... so, we likely should close those out, before any official merge to "master"
[20:06] <mhwood> I've begun tinkering with integration tests that can drive the UIs. Not working yet but getting close to a smoke test for REST.
[20:06] <tdonohue> Shall we go through those PRs quickly today? Or are there any other immediate updates/questions/comments?
[20:06] <bram-atmire> sounds good
[20:07] <mhwood> Yes, PRs. I want to see this merged.
[20:07] <tdonohue> Ok, those PRs are at: https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[20:07] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3ADS-2701-service-api
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:07] <tdonohue> Oh wait, there's 4. I was wrong :)
[20:08] <tdonohue> from the top.. DSPR#1082
[20:08] <kompewter> [ https://github.com/DSpace/DSpace/pull/1082 ] - [DS-2776] Migrate primitives in sql by KevinVdV
[20:08] <mhwood> I think we decided that one would have to wait.
[20:08] <tdonohue> mhwood: yea, we'll get to that last one (which was discussed previously)
[20:09] <tdonohue> 1082: looks correct to me. I haven't had a chance to fully test...but the SQL looks right
[20:10] <mhwood> Same here.
[20:10] <tdonohue> KevinVdV, I'm assuming this has been tested with upgrades?
[20:11] <KevinVdV> Yeah a quick test has been made, not all of these will be required, but we wanted to be sure
[20:11] <KevinVdV> To avoid nullpointer issues with variables
[20:11] <tdonohue> yes, I'd rather set them all to valid values (as you've done) than risk those NULLs causing issues
[20:12] <tdonohue> Ok, I'm +1. I say we merge this (and we can do more test upgrades later to verify all were caught)
[20:12] <mhwood> Yes.
[20:12] <bram-atmire> +1
[20:12] <tdonohue> Ok, merging now.
[20:12] <tdonohue> done
[20:13] <tdonohue> Next up, DSPR#1081
[20:13] <kompewter> [ https://github.com/DSpace/DSpace/pull/1081 ] - DS-2701: Bug fix, cleanup and pgcrypto checking by tdonohue
[20:13] <tdonohue> (I have to somewhat apologize for this one. It's several fixes/improvements in one, all of which are described... I ran into small bugs as I was trying to enhance how we detect pgcrypto, etc)
[20:14] <KevinVdV> Did a quick check, don’t see any problems at first sight
[20:14] <KevinVdV> If this has been tested (which I assume you did ?), then I would say that this is good to merge
[20:14] <tdonohue> But, the end goal here is that "./dspace database migrate" now fails with a descriptive message if you don't have pgcrypto >=1.1. And "./dspace database info" now tells you what is missing if pgcrypto isnt' there, and how to likely resolve it
[20:15] <tdonohue> I've tested this extensively with pgcrypto installed, not installed, out-of-date, etc. I tried to test every scenario I could think of
[20:15] <mhwood> I agree, we need this in.
[20:15] <peterdietz> does the ant update process check the migration capability?
[20:15] <KevinVdV> ant update migrates the database so yeah a check will happen
[20:15] <tdonohue> peterdietz: yes, right now Ant runs "./dspace database migrate"
[20:16] <peterdietz> okay. then this sounds good to me
[20:17] <tdonohue> Ok, merging then. I'll be glad to bug fix on this one if we find issues.. but, I did test thoroughly as I *know* we will get questions on 'pgcrypto' issues, and wanted to "catch" most of them
[20:17] <tdonohue> merged
[20:18] <tdonohue> Next up, DSPR#1077
[20:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/1077 ] - Save collections to community object by terrywbrady
[20:18] <terry-b> A very simple change
[20:18] * aschweer (~andrea@d157.itstaff.waikato.ac.nz) has joined #duraspace
[20:18] <aschweer> morning all
[20:18] <mhwood> Good morning.
[20:18] <peterdietz> terry-b: does that mean that nested-nested data shows up?
[20:18] <tdonohue> hi aschweer: we're reviewing what is left of the PRs against the Service API branch
[20:19] <mhwood> Yes, a very simple change.
[20:19] <aschweer> tdonohue: thanks, I caught up on the log
[20:19] <terry-b> peterdietz, can you elaborate?
[20:19] <tdonohue> terry-b: I'm assuming you've tested this fix? It looks reasonable at a glance..but I don't know this area of code well
[20:20] <terry-b> I have tested this as I was working on another PR.
[20:20] <peterdietz> if you have a community, with lots of collections, and each of those collections have lots of items.. Will the expand propgate down, and expand all fo that
[20:21] <peterdietz> that would be my only concern. top-communities?expand=all, to crash because you've just loading the entire repository
[20:21] <terry-b> I did not test for that explicitly.
[20:21] <terry-b> The objects were being constructed but not returned
[20:22] <peterdietz> okay, then that looks like an omission. +1.
[20:22] <KevinVdV> This seems pretty straightforward to me
[20:22] <tdonohue> agreed.
[20:22] <KevinVdV> Prob works the same as before
[20:22] <tdonohue> I'll merge it then
[20:22] <terry-b> There is another bug I found that I have not yet tried to fix: https://jira.duraspace.org/browse/DS-2766
[20:22] <kompewter> [ [DS-2766] /rest/collections/xxx?expand=parentCommunityList only returns 1 parent community - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2766
[20:22] <aschweer> yeah the communities block just below Terry's change populates the field (rather than a local variable as in the collections case)
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2766 ] - [DS-2766] /rest/collections/xxx?expand=parentCommunityList only returns 1 parent community - DuraSpace JIRA
[20:23] <tdonohue> merged
[20:23] <tdonohue> The last one is DSPR#1039, which was previously discussed /delayed
[20:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/1039 ] - DS-2730 link getName() to DSpaceServices by pnbecker
[20:24] <peterdietz> thanks for helping. My lunch breaks haven't been as productive as Kevin's
[20:24] <tdonohue> I suspect we should close this PR..as it doesn't seem useful to keep this open once we merge over to "master"?
[20:24] <KevinVdV> Indeed + it requires additional refactoring
[20:25] <tdonohue> Or, let me revise that... I suspect we should close this PR *once* we merge to master (which I'm assuming will be shortly/soon, but we'll do that next)
[20:25] <KevinVdV> Altough I support the idea the PR needs work
[20:25] <tdonohue> exactly. good idea, but PR is unfinished
[20:26] <mhwood> Yes, the author is out of office for a while, so it's not likely to be fleshed out soon either.
[20:26] <peterdietz> Pascal is/was in NYC, perhaps he ran into the pope, and got a +1 on the code
[20:27] <tdonohue> Ok. so that brings us to the end of the list of PRs for Service API
[20:28] <tdonohue> The next question is, are we ready to officially merge the "Service API" branch into "master"? (Which means all future changes will go through our normal PR workflow process obviously)
[20:29] <mhwood> Let me turn that around: is there any reason *not* to merge to master?
[20:29] <tdonohue> As part of this we also will need to see which existing PRs break (and notify those PR creators to please rebase/refactor)
[20:30] <peterdietz> I haven't run services latest code. Does it successfully allow for db / data migration from previous version?
[20:30] <tdonohue> mhwood: I see no reason myself.
[20:30] <peterdietz> Last time I ran it, I had to start with fresh db
[20:30] <mhwood> Nor do I.
[20:30] <KevinVdV> It should perform migrations just fine.
[20:30] <KevinVdV> I ran some tests with databases that I had locally & found no issues so far
[20:30] <tdonohue> peterdietz: yes. I've had success recently as well
[20:31] <KevinVdV> Doesn’t mean that there won’t be any…… but that is what testing is for
[20:31] <peterdietz> Sounds like merging to master is the appropriate next step. I don't have an objection
[20:32] <bram-atmire> +1
[20:32] <tdonohue> By merging into "master", we definitely are *not* saying there's "no bugs". But, we are saying "this is looking great, and it's ready for broader use & bug fixing in preparation for 6.0"
[20:32] <mhwood> +1
[20:32] <tdonohue> +1
[20:32] <aschweer> +1
[20:32] <peterdietz> +1
[20:32] <terry-b> +1
[20:32] <KevinVdV> Well obiviously +1 from me ;)
[20:32] <tdonohue> Ok, looks like we are unanimous here! :)
[20:33] <mhwood> Do we need an email vote, or is a simple quorum enough. The work was already approved in principle.
[20:33] <tdonohue> mhwood: good point/question.
[20:33] <bram-atmire> I guess release schedule is the next topic, but I don't see any advantages in delaying this even further
[20:34] <tdonohue> We voted on adding Services API to 6.0 already...that was approved (by everyone). I don't see any reason why anyone would object, and I did make it clear on dspace-devel /-commit recently that we'd be talking about merging into "master" today (and have had no negative feedback as of yet)
[20:35] <mhwood> I just wanted to recall whether another email vote was promised or implied, so that we don't surprise anyone.
[20:36] <mhwood> If we are following the procedure already discussed, good enough.
[20:36] <tdonohue> So, essentially, I'm taking that as a "tacet" approval for what is going on. We could give folks 24 hours (or something like that) to raise final objections?
[20:37] <tdonohue> But, in doing so, we'd have to be clear that "final objections" would need to be based on the *code* not the concept (and frankly this all would be hard to review in 24 hours)
[20:37] <bram-atmire> I'm rather in favor of merging now, since we have such a broad attendance today, so that we can focus on the next steps, but that's just my personal opinion.
[20:37] <tdonohue> Another route here...is we "tag" master immediately & then merge. If someone feels strongly enough, we can revert to that "tag". If not, we keep pushing forward
[20:38] <terry-b> What does tag master mean?
[20:38] <bram-atmire> that tag seems definitely like a good idea. "last commit before the service-api merge"
[20:39] <tdonohue> terry-b. It just means we capture the "state" of master prior to this merge. That way if we needed to, we can easily revert to that "state"
[20:39] <mhwood> I found the vote-closed email. I don't see any further procedural steps being required. Just the code.
[20:39] <terry-b> makes sense. thanks
[20:39] <mhwood> Tagging is cheap and sensible.
[20:40] <tdonohue> Ok, so I think we'll go with that route then.... (1) We tag master. (2) We merge services api branch into master
[20:40] <mhwood> " Once all modules have been fixed (i.e. they all compile), we'll
[20:40] <mhwood> merge the "DS-2701-service-api" branch into "master", and proceed
[20:40] <mhwood> with more detailed (manual) testing of all modules/features to find
[20:40] <mhwood> any immediate bugs."
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:40] <tdonohue> mhwood: thanks for pasting in my language on that vote :) Seems pretty clear now that we can move forward
[20:42] <tdonohue> One other thing to note here on this merger... We will be "breaking" (most/many) existing PRs once this is merged into "master". We've warned folks plenty of times, but I do wonder if we should "clean up" our docs/guides to prep for that. I've noticed our wiki pages are a bit outdated now (as the code has been enhanced some, etc)
[20:42] <tdonohue> Namely, we should review the following to ensure they are still accurate:
[20:42] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api (most of it should be accurate, but there's been some minor changes I think)
[20:42] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:43] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+service+based+api%3A+Porting+DSpace+modules (probably should be deleted / moved elsewhere. Inaccurate now)
[20:43] <kompewter> [ DSpace service based api: Porting DSpace modules - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+service+based+api%3A+Porting+DSpace+modules
[20:44] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api%3A+API+Changelist (probably should just be double checked)
[20:44] <kompewter> [ DSpace Service based api: API Changelist - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api%3A+API+Changelist
[20:45] <tdonohue> Anyone willing to help chip in on cleaning these up a bit, reviewing them? I'd hate to confuse folks who want to rebase/refactor their PRs with inaccurate docs
[20:45] <mhwood> At the very least, if we get a question on discrepancies, we should answer it in the wiki and provide a pointer.
[20:46] <tdonohue> true
[20:46] <mhwood> I'm willing but don't yet know how to start. I'll have to stare at it a bit.
[20:46] <tdonohue> I know the "Porting page" is the most out-of-date. It was based on the initial codebase..so it recommends things like "disabling all modules" and other things that are no longer needed (obviously)
[20:47] <tdonohue> The other two pages are likely "mostly accurate"
[20:47] <mhwood> Oh, yes, of course.
[20:47] <tdonohue> OK. I'll also take a look closer at the porting page a bit
[20:47] <tdonohue> Moving on (as we are low on time here)
[20:48] <tdonohue> Oh, and I forgot. Anyone wish to do the honors on tagging / merging? (Otherwise, I'll find time tomorrow.. I won't get to it today)
[20:49] <peterdietz> anyone have a name for the tag?
[20:50] <bram-atmire> pre-service-refactor ?
[20:50] <mhwood> pre-DS-2701?
[20:50] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:51] <tdonohue> pre-DS-2701 is probably more descriptive. It'll let us also remember what version this happened in (should we ever forget, which I doubt would happen)
[20:52] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:52] <bram-atmire> agreed
[20:52] <tdonohue> Since no one is jumping at this, I'll do the merge tomorrow & announce to dspace-devel. If you need it sooner, feel free to jump on it :)
[20:52] <mhwood> Fair enough.
[20:52] <peterdietz> it wouldn't be ordered like the other tags (I guess those correlate to releases). I was thinking dspace6-pre-services-DS-2701
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:53] <tdonohue> peterdietz: at least in github, tags are ordered by *date* not by name: https://github.com/DSpace/DSpace/tags
[20:53] <kompewter> [ Tags · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/tags
[20:54] <tdonohue> Moving on to last topic for today: 6.0 Timelines
[20:54] <tdonohue> Obviously, we are *not* going to meet our existing timelines, which had the deadline for PRs as *TOMORROW* :)
[20:55] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-TimelineandProcessing
[20:55] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-TimelineandProcessing
[20:55] <mhwood> There's no RT yet, so the timing is conjectural.
[20:55] <tdonohue> So, the question is, what is a reasonable timeline for our "Deadline for PRs"? Do we give developers (and us) another month?
[20:56] <mhwood> "Another month" is what I was thinking.
[20:57] <tdonohue> At this point, I suspect we're doing this release without an RT (Release Team). Which essentially means the Committers are the Release Team, and we'll/I'll have to twist everyone's arms to get folks to take on tasks :)
[20:58] <tdonohue> That is, unless someone is interested in helping out / joining an "ad hoc" RT? I'd still love to have an RT, but I haven't had much luck finding one yet
[20:58] <KevinVdV> I can be on the team, but prefarably not as team lead
[20:58] <tdonohue> KevinVdV thanks!
[20:59] <KevinVdV> I will prob be involved in the reviewing/guiding anyway
[20:59] <tdonohue> very true.
[20:59] <KevinVdV> But I will be out of action for 2 weeks in november as my wife & are I expecting our second child.
[20:59] <bram-atmire> i will be following up on a test plan for end users / repo admins cfr https://wiki.duraspace.org/display/cmtygp/DSpace+6+Testathon+Testplan+Working+group
[20:59] <kompewter> [ DSpace 6 Testathon Testplan Working group - Community Groups - DuraSpace Wiki ] - https://wiki.duraspace.org/display/cmtygp/DSpace+6+Testathon+Testplan+Working+group
[20:59] <tdonohue> Anyone else interested in joining the RT? (I'm pretty much always a "member" so, I'm kinda on it already)
[20:59] <bram-atmire> and would also be willing to do some docs work
[21:00] <tdonohue> bram-atmire: thanks as well
[21:00] <mhwood> Keep asking me. :-)
[21:01] <mhwood> I'm still hoping to see a new face or two on the RT.
[21:02] <tdonohue> regarding timelines. If we give everyone one more month for PRs (or rebasing/refactoring), that'd put us at around Oct 29 for PR deadline, Feature Freeze around mid-to-late-Nov. Testathon would unfortunately start to fall near end of year (or early the next year).
[21:02] <mhwood> Not *too* bad.
[21:02] <tdonohue> It's not an "ideal" schedule. But, I don't see how 6.0 is going to be "ready" in 2015 at this point.
[21:03] <tdonohue> It's more likely we're looking at ~Feb 2016 for final release
[21:03] <mhwood> Like my bank said about being last in town to introduce ATMs: "we waited to bring you the best."
[21:03] <tdonohue> Thoughts on this?
[21:04] <bram-atmire> I think extending the schedule and by doing that, assuring that additional features/improvements come in, is better than the alternative to release a "lighter" release earlier on.
[21:04] <tdonohue> Personally, I think we'd need to avoid an "end of year" Testathon. But, if it got to that, we could push it to early January.
[21:05] <aschweer> ~Feb 2016 for 6.0 sounds realistic to me
[21:05] <mhwood> We all know that the Services refactor is a big deal, but if we set the PR deadline too soon, we'll have few user-oriented changes.
[21:05] <tdonohue> mhwood ++
[21:06] <tdonohue> Ok, so it sounds like we have a new "rough" schedule, which begins with a PR Deadline of Thurs, Oct 29. I'll map that out on our 6.0 Status page (the rest of the dates will be a bit tentative anyways)
[21:06] <mhwood> If Testathon has to slip to the second week of January, so be it.
[21:06] <mhwood> Thanks tdonohue.
[21:07] <tdonohue> Any last questions / thoughts / concerns? (Otherwise, that's the last of my topics for today)
[21:08] <mhwood> Nothing here.
[21:08] <tdonohue> Ok, not hearing any. We'll close up today's meeting (I'll still be around for a bit though if something comes up)
[21:08] <bram-atmire> thanks!
[21:08] <mhwood> Must go. Thanks, all!
[21:08] <tdonohue> thanks all! It's AWESOME that Services API is now ready!
[21:08] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:08] <KevinVdV> Until next week guys ! Need to run & thx all for the help with the service api !
[21:09] <KevinVdV> Really mean a lot to me that it is going in master after starting over a year & half ago
[21:09] <aschweer> I agree, exciting that the merge is coming up, great work everyone
[21:09] <tdonohue> KevinVdv: And thanks for all the hard work you've put into this!
[21:10] * KevinVdV (~KevinVdV@d54c5104d.access.telenet.be) Quit (Quit: KevinVdV)
[21:10] * bram-atmire (~bram@94-225-37-203.access.telenet.be) Quit (Quit: bram-atmire)
[21:11] * aschweer (~andrea@d157.itstaff.waikato.ac.nz) Quit (Quit: leaving)
[21:13] * terry-b (~chrome@71-212-24-25.tukw.qwest.net) Quit (Ping timeout: 246 seconds)
[21:43] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
[22:53] * cknowles (uid98028@gateway/web/irccloud.com/x-pcjcvpfmpusjndyb) Quit (Quit: Connection closed for inactivity)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.