Timestamps are in GMT/BST.
[0:43] * hpottinger (~hpottinge@72-161-217-98.dyn.centurytel.net) has joined #duraspace
[0:52] * hpottinger (~hpottinge@72-161-217-98.dyn.centurytel.net) Quit (Remote host closed the connection)
[2:52] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[3:07] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Quit: Bye)
[6:49] -card.freenode.net- *** Looking up your hostname...
[6:49] -card.freenode.net- *** Checking Ident
[6:49] -card.freenode.net- *** Found your hostname
[6:49] -card.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) 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
[12:18] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:38] * tdonohue (~tdonohue@c-98-212-150-72.hsd1.il.comcast.net) has joined #duraspace
[12:39] * test (55eac36d@gateway/web/freenode/ip.85.234.195.109) has joined #duraspace
[12:39] * test is now known as Guest12620
[12:43] * Guest12620 (55eac36d@gateway/web/freenode/ip.85.234.195.109) Quit (Ping timeout: 246 seconds)
[13:49] * hpottinger (~hpottinge@mu-160070.dhcp.missouri.edu) has joined #duraspace
[15:00] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-29
[15:00] <kompewter> [ DevMtg 2015-07-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-29
[15:01] * ben_bosman (~ben@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:01] <tdonohue> Wow, our attendance looks to be small today (smaller than normal). Hopefully we have others join shortly
[15:01] <mhwood> Hi
[15:02] <tdonohue> Pinging the Committers though: helix84, hpottinger, mhwood, ben_bosman (hi Ben)
[15:02] <hpottinger> I'm here, but I need to step away for about a minute, brb
[15:03] <tdonohue> OK, we seem to be a tiny group today, but I guess we can jump right in. I'm going to reorder things ever so slightly in the Agenda (to see if others show up in a few minutes): https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-29
[15:03] <kompewter> [ DevMtg 2015-07-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-29
[15:03] <tdonohue> So, we'll start at 5.3 updates/notes.
[15:03] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) has joined #duraspace
[15:04] <tdonohue> Just as a general update, Kim Shepherd released 5.3 last night. There's a few last steps to be completed later today (once Kim is back awake, it's the middle of the night for him right now). So, 5.3 should be announced either late today or early tomorrow
[15:04] <tdonohue> But, for anyone wanting 5.3 immediately it is out in Maven Central :)
[15:05] <hpottinger> back
[15:05] <tdonohue> Now we'll hop back to our first topic. Discussion of the Service API work (which ben_bosman presented last week): https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[15:05] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[15:06] <tdonohue> Since you've all seen this work last week and have had some time to review the wiki page / slides, etc, what feedback do you have to share? Or are there any additional questions that have come up?
[15:07] <tdonohue> I'll admit I've heard some positive chat in #dspace last week (mostly from folks here). But, I haven't heard much via email. So, I'll just say again for all here (or others reading these logs later), I really *want* your feedback
[15:07] <hpottinger> Only way for us to get up to speed on it is to, um, get up to speed on it, and that's the only way we'll be able to support it
[15:08] <hpottinger> I'm OK with jumping in, I really like the idea of handing off the constant worry of where the next Oracle bug will come from to another group entirely :-)
[15:08] <tdonohue> hpottinger: from a development / ongoing maintenance standpoint, that's true. I guess the question I'd pose is, "would you like to see this in DSpace? Or are there any concerns / outstanding questions you have first?"
[15:09] <hpottinger> My only worry is one of support, but the only way to deal with that is to get this work into the code base early, so we can gain some experience with it
[15:09] <mhwood> Support..?
[15:10] <ben_bosman> I also see the serviced based API as going much further as only hibernate
[15:10] <hpottinger> "support" = "how does this work? what do we do now? this part seems a bit broken, what next?"
[15:10] <ben_bosman> the hibernate part is just a small fraction
[15:11] <hpottinger> true, ben_bosman, it's our missing business logic layer :-)
[15:11] <ben_bosman> making everything much easier to adjust/extend is an even more important part as we see it
[15:11] <mhwood> Indeed, ben_bosman, my main comment is that this is at least three distinct changes.
[15:12] <hpottinger> so, I'm all for getting this into 6, so we can focus on documenting it
[15:12] <ben_bosman> regarding support, we have the first elaborate documentation on the wiki
[15:12] <tdonohue> hpottinger: I do agree there may be some "early pain points" as we all get more comfortable with the changes. But, to be honest, I feel those are all things we can get through (especially since we'll need to help chip in immediately on updating all our UI layers to use the new API)...so it's likely any "pain points" will hit *prior* to the 6.0 release.
[15:13] <ben_bosman> and we will be working on a list of the actual changes as soon as Kevin returns from his leave
[15:13] <ben_bosman> so documenting it and creating tutorials is a high priority for us
[15:13] <ben_bosman> assuming we get positive feedback, but it seems good so far
[15:13] <tdonohue> +1 ben_bosman. tutorials & even more docs would be excellent.
[15:14] <mhwood> The initial documentation helps a lot in untangling the various changes. Thanks to you all.
[15:15] <ben_bosman> What I would advise for those interested in digging in, is to check out the unit tests
[15:15] <tdonohue> My personal opinion here is that it all "sounds great" to me. After the talk, I've thoroughly read the entire wiki page, and I have no major concerns myself. I would like to see more "examples in action" (which I hope a tutorial will help with), but it honestly sounds/looks good.
[15:15] <ben_bosman> they contain a typical flow for most API actions
[15:15] <tdonohue> ben_bosman: nice idea. I hadn't looked at the Unit Tests quite yet
[15:15] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) Quit (Remote host closed the connection)
[15:16] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) has joined #duraspace
[15:17] <mhwood> What you want to do is all good, I think. I'm still trying to comprehend *how* it's being done. I must admit that I haven't finished the reading I'd intended.
[15:17] <ben_bosman> I think we can start working on the tutorials from these unit tests as well, which should allow us to create at least a first set quite soon
[15:18] <ben_bosman> I’ll think about a good format, and might even be able to have someone work on them prior to Kevin’s return, since there seems to be quite some interest to get themù
[15:18] <hpottinger> this isn't yet a PR, do we need a detailed outline of what needs to happen before this work can be a PR?
[15:20] <ben_bosman> I’ll have to check those details with Kevin
[15:20] <hpottinger> coming at that question a bit differently: how do we see this work being done? I'm assuming @mire will continue developing the code, would this be a candidate for a "feature branch"?
[15:20] <tdonohue> hpottinger: I think we definitely need a *plan* for getting this in. As was noted last week, this change obviously may break other PRs in consideration for 6.0. So, we may need to determine the best route towards tackling that issue
[15:20] <mhwood> My thought as well.
[15:20] <ben_bosman> I didn’t go into the details about how he did the development in git
[15:21] <tdonohue> I like the idea of treating this as a common feature branch...which others could collaborate on. But, we'd need a timeline for getting this merged in as "master" will be a moving target (as other PRs get merged, etc)
[15:22] <hpottinger> we don't yet have an RT for 6, correct?
[15:22] <mhwood> The first merge from feature branch to master should come fairly soon. But, with something this big, it may be good to keep a feature branch open for a while.
[15:22] <tdonohue> So, creating a "feature branch" off DSpace/DSpace would allow @mire to finish up API-level work, while others could start to "fix" XMLUI, JSPUI, LNI, etc. Again though, we'd need to make developers aware of how this will effect existing PRs.
[15:23] <mhwood> I think we need to be wary of letting this work become isolated in its own branch. Merges should start early and happen often, until the code settles down to the point that we can do a final merge and continue fixing/extending in the main line.
[15:24] <ben_bosman> the problem is of course also that the current code doesn’t contain a fully functional DSpace
[15:24] <ben_bosman> we have an operational XMLUI, for most of the features
[15:24] <ben_bosman> but e.g. JSPUI, OAI are not operational, and probably don’t even compile
[15:25] <ben_bosman> so it will be hard to have any other PRs start from this branch, unless they only use code which was already porteed
[15:25] <tdonohue> hpottinger: that's correct, we don't yet have a Release Team for DSpace 6. But, in some ways, assuming Services API is in 6.0, whoever is involved with the Services API may end up having to help "coordinate" things to get it in and ensure stability, etc. I think we'll need a group to do that coordination (not just @mire)...and that group essentially would be doing RT-like tasks
[15:25] <tdonohue> mhwood: good point
[15:25] <mhwood> So that would be the first stuff to work on in the branch: get various bits working again.
[15:26] <hpottinger> yeah, I was thinking feature branch just to get the work into shape for a PR, PR "soon" and then roll with the waves
[15:27] <hpottinger> I'm just thinking we're asking questions about schedules, and the 6.0 schedule doesn't exist yet, because the team doesn't exist yet
[15:27] <tdonohue> Perhaps it would be best to "merge when dspace-api compiles/tests succeed". This will break master for all the UIs. But, we can then work to fix each one-by-one. Plus, PRs can be updated based on the new dspace-api (as needed).
[15:27] <hpottinger> heh "sometimes it's OK to break master"
[15:28] <terry-b> I am excited by this proposed change. (I have studied it beyond attending the call last week.) My gut reaction is that this is a big change. What is this likely to do to the anticipated 6.0 schedule (and the follow on roadmap plans?
[15:28] <tdonohue> hpottinger: I agree, not having a 6.0 schedule or RT is worrisome in general. Perhaps we just need to do a tentative schedule drafted that seems reasonable.
[15:29] <hpottinger> in the past, we've just re-used the old schedule, but I know that some people have concerns about previous timing, and we just keep kicking that can down the road
[15:30] * hpottinger would like to make it clear he's not on the RT this time around :-)
[15:30] <tdonohue> terry-b: later roadmap plans should not be affected too much (as long as the API is stable by end-of-2015 when new UI work is scheduled to begin). But, it *might* affect the 6.0 schedule, depending on what limitations we place on what will be in 6.0
[15:31] <tdonohue> But, what terry-b does bring up is a good point. We don't want 6.0 to get pushed back too far. If we did, we'd be "splitting" resources between "finishing 6.0" and "starting new UI development"
[15:32] <tdonohue> Ideally, 6.0 is *finished* prior to "new UI development"....and "new UI development" is tentatively scheduled for early 2016
[15:32] <ben_bosman> for the service based api work: our estimates are a few weeks of development work left to get all the modules work (apart from bugs we encounter later-on)
[15:33] <hpottinger> 5.0 schedule: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[15:33] <tdonohue> Honestly though, now *is* the best time for this big of a change to get in. Delaying Services API for 7.0 could prove even harder as you'd be developing a new UI on a new API. Ideally we split that into two releases
[15:33] <ben_bosman> with a few people interested in working on this, I think it should be possible to get a first version ready at a reasonable time, so the other PRs can be updated based on this contribution
[15:33] <kompewter> [ DSpace Release 5.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-TimelineandProcessing
[15:34] <tdonohue> ben_bosman: thanks for those timelines. Honestly it does sound doable, if we can get others to chip in immediately
[15:34] <hpottinger> right, tdonohue, 6.0 is the logical time to do any major refactoring we want to do in the lead-up to 7.0
[15:35] <tdonohue> So, if we look at the 5.0 timelines as a reference (which hpottinger pasted in), ideally we'd have 6.0 "PR Deadline" in late Sept / early Oct. That'd give us essentially a little over 2 months
[15:36] <tdonohue> Earlier is obviously *better*. But, that'd line up with what we did with 5.0
[15:36] <terry-b> From a complexity standpoint, will these changes make 6.0 equivalent in complexity to other recent releases or does this make 6.0 an evolutionary release?
[15:37] <ben_bosman> for complexity: I guess this is the first release where all classes will be updated (except when the license was included in all classes)
[15:38] <hpottinger> tdonohue: "earlier is obviously better" do you mean an earlier PR deadline?
[15:38] <tdonohue> terry-b: 6.0 would be a bit more evolutionary than normal (as much of the API changes), but it'd be "invisible" mostly (assuming we get any bugs ironed out)
[15:38] <tdonohue> hpottinger: yes...the earlier we can get all the PRs ready for review/merger the better. So, ideally we'd do that by late Sept, if possible
[15:39] <tdonohue> (which gives us 2 months)
[15:39] <hpottinger> need to plan out work for a year? this helps: http://davidseah.com/node/compact-calendar/
[15:39] <kompewter> [ The Compact Calendar - Dave Seah ] - http://davidseah.com/node/compact-calendar/
[15:41] <tdonohue> So, it sounds like those in attendance today are leaning towards getting this into 6.0. We've identified we need a 6.0 Tentative Schedule. It seems reasonable to base that off the 5.0 schedule (I can throw a rough draft up on the 6.0 Status page)
[15:41] <hpottinger> How about Sept 30 for PR deadline?
[15:41] <tdonohue> hpottinger: sounds good
[15:42] <tdonohue> hpottinger: are you already plotting out a rough schedule for 6.0? If so, I'll let you do it :)
[15:43] <tdonohue> It sounds like our discussion on "Services API" is wrapping up a bit though. My plan for this is that we discuss it again next week (20UTC) to catch others opinions. After next week's meeting, I'll call for an "official vote" on whether we'd like to adopt Services API for 6.0.
[15:44] <hpottinger> :-) I'm scribbling on a piece of paper with a calendar printed on it
[15:44] <hpottinger> copy/paste the 5.0 schedule, starting at Sept 30, runs the Testathon into Thanksgiving in the US
[15:45] <tdonohue> (I think this likely warrants a broader vote, just cause of the significance of the change, and the fact that help will be needed to "finish it up", so it's different than a normal PR)
[15:45] <ben_bosman> Kevin will join next week’s meeting
[15:45] <tdonohue> ben_bosman: sounds good
[15:45] <tdonohue> hpottinger: we can tweak the dates a bit around holidays...push Testathon back a week if needed
[15:46] <ben_bosman> and it’s definitely good to do vote after that meeting, so everyone is certain of the release to invest the remaining work
[15:46] <tdonohue> Any last thoughts/questions on Services API? (If not, we'll move on to other topics for today.)
[15:47] <hpottinger> OK, so... if the PR deadline is 9/30, that means ideally the Services API needs to come in either early September or late August.
[15:48] <tdonohue> hpottinger: yes, ideally Services API in late August if we can swing that
[15:48] <tdonohue> As that'd give a month for PR cleanup (and "master" cleanup/testing/fixing)
[15:48] <ben_bosman> should be doable if we get the support we hope for
[15:48] <tdonohue> +1
[15:49] <tdonohue> Ok, we'll pick this up again next week then. In the meantime, if anyone has feedback to share (publicly or privately), please do so on mailing lists (or email me privately). I'll update everyone next week on any feedback I've heard
[15:49] <hpottinger> heh, I just crossed off all the days that are already gone out of 2015... makes it clear we've got about 3-6 weeks before this code should be merged
[15:50] <hpottinger> that's 2-3 sprints
[15:50] <tdonohue> hpottinger: yep
[15:51] <tdonohue> Ok, moving along to other topics here. Most everything else is general updates...but things worth mentioning
[15:51] <tdonohue> Regarding the SourceForge move... we plan to release 5.3 via GitHub (with SourceForge as a backup, assuming they allow us to upload release packages again).
[15:52] <tdonohue> The mailing list migration stuff is still a work-in-progress. I've run into issues with migrating easily to Google Groups (from SF). But, I've got a few more ideas to try
[15:53] <tdonohue> (If I cannot get a clean archive over to Google Groups, we may need to decide if we either "split" our archive or go to something other than Google Groups...but, I still have a few more things to try before we come to that)
[15:54] <tdonohue> That's it for the SourceForge migration updates for now
[15:54] <tdonohue> Regarding 6.0, we've already talked a fair amount about it, and drafting a tentative schedule. I don't think I have anything else to mention that isn't in the agenda
[15:55] <hpottinger> where should I put this draft schedule for 6?
[15:55] <tdonohue> on the 6.0 status page :)
[15:55] <hpottinger> that seems so... official :-) but OK
[15:56] <tdonohue> The last thing is an update on the RoadMap work. We are in the midst of scheduling an initial "UI Working Group" meeting (in early August). Once the meeting date/time is set, an email will go across mailing lists inviting anyone to join the meeting
[15:56] <mhwood> Just make sure it actually says "draft".
[15:57] <tdonohue> The goal of the meeting will be to formalize a "UI Working Group" team, and their charter...and also start to kick off the UI prototyping process.
[15:57] <tdonohue> A rough draft of the UI Working Group charter / schedule is up on the wiki at: https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Working+Group
[15:57] <kompewter> [ DSpace UI Working Group - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Working+Group
[15:58] <tdonohue> Those are all the updates I have, but I'll pause now for questions/thoughts if there are any :)
[16:00] <tdonohue> Ok. Anything else folks have to discuss / bring up for today?
[16:00] <terry-b> Not from me
[16:01] <tdonohue> Well, thanks all then for joining us today. We'll go ahead and close up the meeting. I'll be around though if questions do come up! See you next week at 20:00 UTC!
[16:03] <hpottinger> draft schedule up: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[16:04] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[16:04] <mhwood> Thanks!
[16:04] <hpottinger> That's enough RT duty for me, I again resign :-)
[16:06] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) Quit (Ping timeout: 260 seconds)
[16:11] * peterdietz (uid52203@gateway/web/irccloud.com/x-hdfjeckbrjctwhqo) has joined #duraspace
[16:15] <hpottinger> shoot, DSPR#999 would have been cool to get into 5.3
[16:15] <kompewter> [ https://github.com/DSpace/DSpace/pull/999 ] - [DS-2679] Retain ordering of authors for Google Scholar metatags. by christian-scheible
[16:25] * ben_bosman (~ben@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 240 seconds)
[16:43] * hpottinger (~hpottinge@mu-160070.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[18:04] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[18:05] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[19:46] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[20:20] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[21:00] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:37] * tdonohue (~tdonohue@c-98-212-150-72.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.