Timestamps are in GMT/BST.
[6:49] -orwell.freenode.net- *** Looking up your hostname...
[6:49] -orwell.freenode.net- *** Checking Ident
[6:49] -orwell.freenode.net- *** Found your hostname
[6:49] -orwell.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
[8:38] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[10:00] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (*.net *.split)
[10:07] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[10:17] * pnbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[10:23] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (*.net *.split)
[11:50] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:13] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[13:12] * peterdietz (~peterdiet@h21.125.130.174.dynamic.ip.windstream.net) has joined #duraspace
[13:17] * peterdietz_ (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[13:17] * peterdietz (~peterdiet@h21.125.130.174.dynamic.ip.windstream.net) Quit (Ping timeout: 240 seconds)
[13:17] * peterdietz_ is now known as peterdietz
[13:33] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[13:40] * peterdietz_ (~peterdiet@h21.125.130.174.dynamic.ip.windstream.net) has joined #duraspace
[13:41] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Ping timeout: 272 seconds)
[13:41] * peterdietz_ is now known as peterdietz
[13:46] * hpottinger_ (~hpottinge@173.154.243.227) has joined #duraspace
[13:49] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Ping timeout: 272 seconds)
[13:54] * hpottinger_ (~hpottinge@173.154.243.227) Quit (Read error: Connection reset by peer)
[13:58] * hpottinger (~hpottinge@173.154.243.227) has joined #duraspace
[14:22] * peterdietz (~peterdiet@h21.125.130.174.dynamic.ip.windstream.net) Quit (Ping timeout: 240 seconds)
[14:23] * peterdietz (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[14:43] * robint (81d7ec36@gateway/web/freenode/ip.129.215.236.54) has joined #duraspace
[14:45] * robint (81d7ec36@gateway/web/freenode/ip.129.215.236.54) has left #duraspace
[14:58] * robint_ (81d7ec36@gateway/web/freenode/ip.129.215.236.54) has joined #duraspace
[14:58] * robint_ (81d7ec36@gateway/web/freenode/ip.129.215.236.54) Quit (Client Quit)
[14:59] * robint (81d7ec36@gateway/web/freenode/ip.129.215.236.54) has joined #duraspace
[15:00] <tdonohue> Welcome all, it's time for our weekly DSpace Developers Meeting. Today's rough agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-08-13
[15:00] <kompewter> [ DevMtg 2014-08-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-08-13
[15:01] <tdonohue> We'll kick things off with the usual DSpace 5.0 reminders ;)
[15:01] <tdonohue> 1) The 5.0 PR Feature Freeze is in less than 2 months (tentative for Oct 6)
[15:02] <tdonohue> 2) We are still in search of a few more 5.0 Release Team members. We can use all the help we can get, especially since we already have a large number of PRs coming in for review & possible inclusion into 5.0
[15:03] <tdonohue> I didn't have anything else specific to mention about 5.0 today. But, I did want to leave some time here if anyone has updates they want to share, or is looking for feedback on something they are working on for 5.0
[15:03] <tdonohue> So, I'll pause for a moment to see if anyone has 5.0 related topics to bring up
[15:04] <robint> Can I jump in selfishly with https://github.com/DSpace/DSpace/pull/601
[15:04] <kompewter> [ DS-2088 Record bitstream downloads as Google Analytics events by robintaylor · Pull Request #601 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/601
[15:04] <tdonohue> go for it, robint
[15:04] <robint> Its pretty small and trivial but is a precursor to other work
[15:04] <tdonohue> Are you just looking for feedback / a review?
[15:04] <robint> Yep
[15:05] <robint> There are lots of things we could record in Google Analytics so I would like to get something committed as an example
[15:05] <mhwood> is recordGoogleAnalytics() redundant between JSPUI and XMLUI? Should it perhaps move to dspace-api?
[15:06] <hpottinger> Sml
[15:06] <robint> mhwood: possibly
[15:06] <hpottinger> Sorry, phone typing...
[15:06] <tdonohue> robint: I like the idea. A minor thing that jumped out at me. The JSPUI and XMLUI have separate configs for Google Analytics. Looks like you are using the XMLUI one for your JSPUI changes: https://github.com/DSpace/DSpace/pull/601/files#diff-10894a23304a3c121db9e80095441fe2R241
[15:06] <kompewter> [ DS-2088 Record bitstream downloads as Google Analytics events by robintaylor · Pull Request #601 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/601/files#diff-10894a23304a3c121db9e80095441fe2R241
[15:06] <mhwood> The idea is sound.
[15:07] <robint> Doh! thanks tdonohue
[15:07] <tdonohue> Yes, +1 to the idea. I also wonder though if we should move the general logic into API somewhere... I hate to duplicate the HTTP post in two places...as it would need to be kept in sync at all times, etc.
[15:07] <robint> mhwood: I think if it grew then into something more substantial it should probably be refactored into dspace-api
[15:08] <tdonohue> robint: true, that's another way of looking at it, I guess
[15:08] <hpottinger> I would say we trust you, if it is a small change.
[15:08] <mhwood> Perhaps just drop a comment on each copy, noting the other copy and the possibility of factoring them out.
[15:09] <robint> Unfortuntely the methods are a wee bit different so its debatable whetehr we would gain anything at the moment by factoring out the common code, but I'll look again
[15:09] <robint> thanks for the feedback
[15:09] <tdonohue> seems reasonable to just drop in a comment, like mhwood says. It's small enough duplication that maybe it's OK for now
[15:09] <tdonohue> After the minor fix & an added comment, I'd say +1 to getting this in
[15:09] <mhwood> OK, I only mention this at first glance, and you know the code better.
[15:10] <robint> Good stuff, I'll not hog the meeting any longer
[15:11] <mhwood> One other comment: if it's simple, you might want a rather short timeout on the exchange.
[15:11] <robint> I'll look at that, thanks mhwood
[15:12] <tdonohue> one last minor thing, robint: There's several "log.info" calls which might be better as "log.debug". Not sure we want to fill up logs with comments of posting things to Google Analytics? E.g. https://github.com/DSpace/DSpace/pull/601/files#diff-10894a23304a3c121db9e80095441fe2R265
[15:12] <kompewter> [ DS-2088 Record bitstream downloads as Google Analytics events by robintaylor · Pull Request #601 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/601/files#diff-10894a23304a3c121db9e80095441fe2R265
[15:13] <robint> Ok, I'll noted these things on the Jira and change the code. Cheers
[15:13] <robint> noted/note
[15:13] <tdonohue> thanks, robint!
[15:13] <tdonohue> Anyone else have something to discuss for 5.0? Or something that is an early dependency for other later work?
[15:14] <hpottinger> Tdonohue, want to mention your new unit test?
[15:14] <tdonohue> I'll go ahead and mention that (in spare time) in the last few weeks, I've done some larger refactoring/cleanup of our Unit Testing framework...all in this bigger PR: https://github.com/DSpace/DSpace/pull/600
[15:15] <kompewter> [ DS-2080 Cleanup bad/broken tests, and upgrade to latest JUnit and JMockit by tdonohue · Pull Request #600 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/600
[15:15] <tdonohue> This PR is fully functional, EXCEPT that it has discovered a "hidden" bug in our API....which hpottinger also logged as DS-2086
[15:15] <kompewter> [ https://jira.duraspace.org/browse/DS-2086 ] - [DS-2086] SQL error thrown when deleting a community: ORA-02292: integrity constraint violated - child record found - DuraSpace JIRA
[15:17] <pnbecker> tdonohue +1 for DS-2080. Great work!
[15:17] <kompewter> [ https://jira.duraspace.org/browse/DS-2080 ] - [DS-2080] Cleanup bad/broken Unit Tests by ensuring they are independent - DuraSpace JIRA
[15:17] <tdonohue> But, in the PR, I've updated our Unit Testing Framework to the latest JUnit, JMocket & H2 database. I've also switched it to use the *ORACLE* database Schema (rather than supporting a separate H2 schema, which we were failing to maintatin)
[15:18] <robint> Does the bug only occur if there are related parent or child communities?
[15:18] <tdonohue> I'm hoping that we can find a way to squash the bug in Ds-2086 very quickly, as I'd like to get these Unit Test fixes into "master" as I think they will stabilize our Travis builds even further
[15:19] <tdonohue> robint: 2086 seems to only occur when you are deleting a Community which has both a Sub-Community and a Sub-Sub-Community
[15:19] <hpottinger> Just want to note my appointment is done, about to drive home, connection will drop, will check back when I get home.
[15:21] <robint> So is the correct behaviour that deleting a community should delete any subcommunities and collections?
[15:21] <robint> Or should we instruct the user that they exist and that they should be deleted first?
[15:22] <tdonohue> robint: currently in the UIs, we warn Admins that deleting a Community will delete any subcommunities & collections & Items under it.
[15:22] <robint> Oh ok
[15:22] <tdonohue> I guess we could *change* that, and tell them to cleanup first. But, it has the potential to lead to a lot of cleanup
[15:23] <mhwood> Looking it over yesterday with hpottinger, it looked to me as though something is calling Community.delete when it should be calling removeSubcommunity. The latter cleans up the community2community table, which is mentioned in the error.
[15:23] <mhwood> I didn't trace things thoroughly....
[15:23] <robint> I could investigate tomorrow, seems a fair trade for getting my PP reviewed today
[15:23] <tdonohue> So, our API *attempts* to actually cleanup everything....but it encounters a Database error right now (at least on both Oracle & H2 -- not sure about PostgreSQL yet)
[15:23] <robint> PP/PR
[15:24] <tdonohue> robint: if you could help investigate, that would be appreciated
[15:24] <tdonohue> mhwood: that is a nice hint...I still haven't had a chance to dig deeply enough to figure out where our logic goes wrong
[15:25] <robint> ok, I've assigned to me and expect to be able to look at it soon
[15:25] * hpottinger (~hpottinge@173.154.243.227) Quit (Read error: Connection reset by peer)
[15:25] * hpottinger_ (~hpottinge@173.154.243.227) has joined #duraspace
[15:25] <tdonohue> robint: thanks!
[15:26] <tdonohue> In any case, that's all I really had to say about the Unit Testing Framework refactoring/cleanup. It's nearly ready to go, but it does throw a "known" error right now cause of 2086.
[15:26] * hpottinger_ (~hpottinge@173.154.243.227) Quit (Read error: Connection reset by peer)
[15:26] * hpottinger (~hpottinge@173.154.243.227) has joined #duraspace
[15:26] <mhwood> Good to have all that cleaned up. Thanks!
[15:26] <pnbecker> currently the Travis CI breaks sometimes on some EPerson tests.
[15:26] <pnbecker> tdonohue: do you think your work will repair that?
[15:26] * hpottinger_ (~hpottinge@161.130.188.149) has joined #duraspace
[15:27] <pnbecker> and as I said before: great work! thanks.
[15:27] <tdonohue> pnbecker: yep...I fixed a ton of tests which can sometimes cause random failures. Essentially there were many areas where our Unit Tests assumed that the tests will be run *in the order that they appear*. However, that is NOT promised by latest JUnit (as Java 7 itself cannot promise order of operations). So, random failures did occur if things were run in different ordering.
[15:28] <pnbecker> :-)
[15:28] <tdonohue> pnbecker: but, I *think* I found and fixed all those tests that could throw random errors
[15:28] * AndChat-288756 (~hpottinge@174-154-231-248.pools.spcsdns.net) has joined #duraspace
[15:29] <tdonohue> Anyone else have updates to share for 5.0? Or anything they are actively working on?
[15:30] <robint> Nothing else to report at the moment
[15:31] * hpottinger (~hpottinge@173.154.243.227) Quit (Ping timeout: 272 seconds)
[15:31] * pnbecker is still working on rdf/linked data support. but nothing to talk about right now.
[15:31] <tdonohue> Ok, not hearing any other specific updates...so we can move along to other topics :)
[15:31] * hpottinger_ (~hpottinge@161.130.188.149) Quit (Ping timeout: 272 seconds)
[15:31] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[15:32] <tdonohue> Next topic: I know this has been in discussion for some time (and I've kinda let this slip)....but I'd like to announce to dspace-tech that we will now *also* support DSpace Q&A on StackOverflow. Any objections or final thoughts on that?
[15:33] <tdonohue> (Actually I'd probably announce that to *all lists*...not just -tech)
[15:33] <pnbecker> no objection. Just - as I wrote you personally before - I think we should use stackoverflow and serverfault.com
[15:33] <pnbecker> both are sides from stack exchange.
[15:34] <pnbecker> stackoverflow is for development, server vault for things that normaly gets discussed on -tech.
[15:34] <pnbecker> s/vaul/fault
[15:34] <kompewter> pnbecker meant to say: stackoverflow is for development, server faultt for things that normaly gets discussed on -tech.
[15:36] <tdonohue> pnbecker: admittedly, it seems like there's already a lot of Install/Config related questions on StackOverflow....even though I understand that ServerFault is *meant* for that, it seems like a ton of overlap already
[15:36] * AndChat-288756 (~hpottinge@174-154-231-248.pools.spcsdns.net) Quit (Ping timeout: 272 seconds)
[15:36] <tdonohue> ServerFault also doesn't yet have a "dspace" tag. I guess we could create one there and also monitor it just in case though
[15:37] * hpottinger_ (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[15:37] <pnbecker> as long as no configuration questions are closed on stackoverflow as not beeing development related, I'm fine with it. :-)
[15:37] <tdonohue> But, I do agree in concept. We'd want to keep an eye on DSpace questions elsewhere on StackExchange sites... I was mostly just wanting to start with StackOverflow
[15:37] <robint> Apologies but I have to sneak away. Cheers all
[15:37] * robint (81d7ec36@gateway/web/freenode/ip.129.215.236.54) Quit (Quit: Page closed)
[15:38] <tdonohue> pnbecker: yep, if folks start closing questions on stackoverflow, we'd definitely need to rethink & restrategize
[15:39] <tdonohue> Any other thoughts on this? Just want to be sure there's no other disagreements before we move forward here..
[15:40] <tdonohue> OK. hearing nothing else. I'll consider the idea "finalized" and go ahead and draft up an announcement to our mailing lists. Then we'll just have to wait to see if anyone decides to use StackOverflow or not
[15:42] <tdonohue> Last topic for today. You may have noticed we are gathering a rather large PR backlog (up to 90 now): https://github.com/DSpace/DSpace/pulls
[15:42] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls
[15:42] <mhwood> I'm subscribed to the dspace tag on SO.
[15:43] <tdonohue> *Most* of these have actually been created in 2014 (57 of them): https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+created%3A%3E%3D2014-01-01
[15:43] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+created%3A%3E%3D2014-01-01
[15:44] <tdonohue> So, we need to strategize how best to start tackling this backlog...especially to help ensure that we can get as many ready for 5.0 as we can
[15:44] <hpottinger_> back home, re the PR backlog, I'd like to ask, if you're a committer and there is a PR in our backlog that belongs to you, if it's a "minor change" please consider merging it. If it's not a minor change, please wrangle the testing you need.
[15:45] <tdonohue> +1 hpottinger
[15:45] <hpottinger_> if you're not a committer, but your PR is minor, find a committer to test and merge for you
[15:46] <hpottinger_> and, if you're not a committer, and your PR is "rather large" you should definitely be wrangling a committer or two to test for you
[15:47] <tdonohue> I'm also considering trying to find an hour or two to go through and quickly "label" all these PRs as "bug" vs. "feature" (if folks think that would be useful). Obviously we have this categorization in JIRA tickets, but it's hard to parse out in GitHub itself.
[15:47] <hpottinger_> Andrea Bolinni last year made a JS fiddle that handled linking up JIRA with GitHub PRs, it was helpful
[15:48] <tdonohue> We may also wish to find a way to "label" any PRs which are essentially "outdated" or unacceptable as-is. I know some of the oldest PRs are basically "broken" or works-in-progress which were never finished
[15:48] <pnbecker> tdonohue: I think it would be more important to see if tickets for all of the prs exists and if they are labled with has pull-request.
[15:48] <hpottinger_> tdonohue: I think you labeled the PRs with a milestone in GitHub?
[15:49] <tdonohue> pnbecker: I think most/nearly all PRs do have a JIRA ticket. But some of those tickets are either waiting to be reviewed or are sitting in the "Needs Code Review" status.
[15:50] <hpottinger_> if we can get a list together of PRs that need review, we can start asking folks to look at that list and chip in
[15:50] <tdonohue> hpottinger: yes, it is possible to create "milestones" in GitHub to essentially "schedule" some PRs for things like "5.0-feature-freeze". We did that last year with the "4.0-feature-freeze"...we flagged certain PRs for that, and concentrated on getting those reviewed
[15:51] <hpottinger_> that was amazingly helpful, if memory serves, basically GitHub's interface took over a job we were doing by hand
[15:52] <tdonohue> The overall issue here is that obviously we are using two systems at once (JIRA & GitHub PRs) which unfortunately don't "sync" well. So, we have to determine what we want to do within each system.
[15:53] <tdonohue> hpottinger_: I think the idea of "Feature-freeze" milestone did work out well. I'd want the 5.0 Release Team to try and help lead that though, even though I'd love to help. We could even schedule this for a future meeting (or "Backlog" hour), if needed
[15:54] <hpottinger_> OK, we'll put our heads together and see what we can do to tie the systems together again
[15:55] <tdonohue> yea...just looking for ideas on how we want to manage this. Some things GitHub does really well (especially searching/filtering PRs), and others JIRA does better (e.g. having a ticket workflow process, etc.)
[15:56] <tdonohue> Mostly, I just wanted to bring this up.. we have a lot of code changes "just waiting" for us...we just need to try and come up with some strategies to review them
[15:58] <hpottinger_> just looking at the PR list can be a bit daunting, I know it helps for us to sort the list into piles: ready to go; needs rebase; etc.
[15:58] <tdonohue> So, ideas are obviously welcome going forward.
[15:58] <hpottinger_> as are volunteers for the RT :-)
[15:59] <tdonohue> Of course! yes, Release Team volunteers are more than welcome :)
[15:59] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Disconnected by services)
[16:00] * hpottinger_ is now known as hpottinger
[16:00] <tdonohue> Ok, we are now at one hour. So, I'm not going to call any more topics for today (besides that's all that was on our agenda). If anyone has agenda topics for next week, feel free to pass them along.
[16:00] <tdonohue> At this point though, the official meeting is adjourned. I'll be hanging around for a while though, if any other topics come up, or anyone has anything informal to discuss
[16:00] * hpottinger_ (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[16:01] * hpottinger_ (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Disconnected by services)
[16:02] <hpottinger> so, I think we had some interest in testing DSPR#600?
[16:02] <kompewter> [ https://github.com/DSpace/DSpace/pull/600 ] - DS-2080 Cleanup bad/broken tests, and upgrade to latest JUnit and JMockit by tdonohue
[16:06] <hpottinger> looking at the transcript, it seems robint volunteered to pitch in with DS-2080 and DS-2086
[16:06] <kompewter> [ https://jira.duraspace.org/browse/DS-2080 ] - [DS-2080] Cleanup bad/broken Unit Tests by ensuring they are independent - DuraSpace JIRA
[16:06] <kompewter> [ https://jira.duraspace.org/browse/DS-2086 ] - [DS-2086] SQL error thrown when deleting a community: ORA-02292: integrity constraint violated - child record found - DuraSpace JIRA
[16:08] <tdonohue> hpottinger: yes, robint said he could try and help look at it tomorrow as needed
[16:08] <tdonohue> and I see he even assigned 2086 to himself
[16:09] <hpottinger> I see the same
[16:09] <tdonohue> It doesn't stop others from digging in as well, I just know he wanted to ensure it got extra eyes
[16:11] <hpottinger> indeed, I can confirm you can test PR #600 in vagrant-dspace pretty easily
[16:12] <hpottinger> also, I'm just tacking this link on at the end of the transcript: http://puppetlabs.com/blog/free-tickets-puppetconf-2014-minorities-tech
[16:12] <kompewter> [ Free Tickets to PuppetConf 2014 for Minorities in Tech | Puppet Labs ] - http://puppetlabs.com/blog/free-tickets-puppetconf-2014-minorities-tech
[16:16] <hpottinger> also, it looks like Mirage2 is one step closer to merging
[16:16] <hpottinger> see DS-2052, most recent comment from Bram
[16:16] <kompewter> [ https://jira.duraspace.org/browse/DS-2052 ] - [DS-2052] Mirage 2 Responsive theme for the XMLUI - DuraSpace JIRA
[16:44] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Quit: Later, taterz!)
[17:23] * pnbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:59] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[18:50] * Disconnected.
[18:50] -barjavel.freenode.net- *** Looking up your hostname...
[18:50] -barjavel.freenode.net- *** Checking Ident
[18:50] -barjavel.freenode.net- *** Found your hostname
[18:50] -barjavel.freenode.net- *** No Ident response
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.