Timestamps are in GMT/BST.
[4:10] * pmp_ (75d34b79@gateway/web/freenode/ip.117.211.75.121) has joined #duraspace
[4:10] <pmp_> hi
[4:10] <pmp_> gud morning to all..
[4:10] * pmp_ is now known as Guest56058
[4:10] <Guest56058> ok
[4:11] <Guest56058> please share avideo link to learn dspace
[4:15] * Guest56058 (75d34b79@gateway/web/freenode/ip.117.211.75.121) has left #duraspace
[6:53] -cameron.freenode.net- *** Looking up your hostname...
[6:53] -cameron.freenode.net- *** Checking Ident
[6:53] -cameron.freenode.net- *** Found your hostname
[6:53] -cameron.freenode.net- *** No Ident response
[6:53] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:53] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:53] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:10] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:22] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[13:22] * peterdietz (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[13:37] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[14:03] * lo5an (~lo5an@unaffiliated/lo5an) has joined #duraspace
[14:06] * lo5an (~lo5an@unaffiliated/lo5an) Quit (Client Quit)
[14:06] * lo5an_ (~lo5an@unaffiliated/lo5an) has joined #duraspace
[14:17] * lo5an_ (~lo5an@unaffiliated/lo5an) Quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[14:30] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[14:58] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Ping timeout: 245 seconds)
[15:00] * peterdietz (~peterdiet@162-231-20-67.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[15:06] * peterdietz_ (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[15:06] * peterdietz (~peterdiet@162-231-20-67.lightspeed.clmboh.sbcglobal.net) Quit (Ping timeout: 260 seconds)
[15:06] * peterdietz_ is now known as peterdietz
[15:39] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[17:06] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:47] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Ping timeout: 250 seconds)
[17:48] * peterdietz (~peterdiet@162-231-20-67.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[18:04] * peterdietz_ (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[18:05] * peterdietz (~peterdiet@162-231-20-67.lightspeed.clmboh.sbcglobal.net) Quit (Ping timeout: 272 seconds)
[18:05] * peterdietz_ is now known as peterdietz
[19:02] * vtkeithg (~vtkeithg@vtkeithg.lib.vt.edu) has joined #duraspace
[19:25] * terryb (~anonymous@162.244.138.212) has joined #duraspace
[19:25] * monikam_ (~Monika_Me@monika.Princeton.EDU) has joined #duraspace
[19:27] * mdiggory (~anonymous@cpe-76-176-128-229.san.res.rr.com) has joined #duraspace
[19:38] * kohts_ (5b4e6f33@gateway/web/freenode/ip.91.78.111.51) has joined #duraspace
[19:39] * kohts_ (5b4e6f33@gateway/web/freenode/ip.91.78.111.51) has left #duraspace
[19:39] * kohts (5b4e6f33@gateway/web/freenode/ip.91.78.111.51) has joined #duraspace
[19:47] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Ping timeout: 240 seconds)
[19:58] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) has joined #duraspace
[19:59] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) has joined #duraspace
[20:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-08-06
[20:01] <kompewter> [ DevMtg 2014-08-06 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-08-06
[20:02] <tdonohue> Today, and for the foreseeable future, the primary topic is 5.0 release, specifically any major features we need to help get in "early", etc.
[20:03] <tdonohue> I also wanted to note that, currently our "Deadline for Feature Pull Requests" is just two months away. So, get your Features in soon, as you only have until early October
[20:03] <hpottinger> and, erm, gathering many, MANY volunteers for the 5.0 RT
[20:05] <tdonohue> Yes, please. ANYONE who would like to help contribute to the Release Team (need not be a Committer, but having some basic Dev chops may help at times) is welcome!
[20:05] <tdonohue> To say this a different way...
[20:05] <tdonohue> WE NEED MORE PEOPLE on the 5.0 Release Team. Otherwise, we risk having TOO FEW REVIEWERS, and risk not being able to get everything we want into 5.0 Release.
[20:06] <tdonohue> (That being said, you can also help do Reviews of PRs even if you are not on the Release Team...it's just that the Release Team sometimes helps push us to get the reviews done in a timely fashion)
[20:07] <robint> I am happy to help out but don't think I would be able to 'officially' volunteer
[20:08] <tdonohue> So, I'll continue to bring this up over and over again :) Honestly, some of your "proposed 5.0 features" will likely not make it in if we cannot find a full Release Team.
[20:09] <hpottinger> :-) robint is being funny, as a former RC he knows he's permanently on the RT :-)
[20:09] <tdonohue> robint: any way folks can help is great. So, we'd love to have folks informally chip in too. But, we do need some more "official" folks to help drive things along (and help organize those informal participants better)
[20:09] <robint> I have a slight concern that there seems to be a group that provide features and a group that get lumbered with reviewing, releasing etc
[20:10] <robint> Being on the release team can get in the way of doing development
[20:11] <mdiggory> who is on the release team for 5.0 todate?
[20:11] <tdonohue> We have two people on the 5.0 Release Team: hpottinger & peterdietz
[20:12] <hpottinger> but it doesn't have to get in the way, honest, if you just attend the meetings and help us make decisions, maybe help us crunch some data... that's all things we need
[20:13] <tdonohue> (And to be crystal clear -- I will likely be on paternity leave around the time of 5.0. So, I will likely not be able to help with 5.0 in the final weeks/month. We will need to plan for others to help support.)
[20:13] <tdonohue> robint: I agree with your first concern. But, I don't think RT *needs* to get in the way of development, as hpottinger notes.
[20:14] <tdonohue> Being on the RT will take some extra time, but the more folks we have, the less time it will pull from your given week. And RT work mostly "ramps up" as feature development is "ramping down" (i.e. post-Feature PR freeze)
[20:14] <robint> Just grumbling a little, don't take it seriously
[20:15] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[20:16] <hpottinger> I hope robint knows I was just kidding, though, as a former RC, he *may* get asked the kinds of questions we normally ask tdonohue when the release date approaches.
[20:17] <tdonohue> So, I really hate to harp on this every week...but we do need more folks to actively participate. Releases don't "magically" happen...and while having some folks concentrating on just building new cool features is good, we need to ensure we are all helping chip in (on occasion) to help releases go smoothly.
[20:17] <mhwood> robint makes a good point about the same set of names winding up on the RT all the time. There is effort this time to resist that and attract some new names. So far that hasn't worked.
[20:17] <tdonohue> mhwood ++
[20:17] <robint> Dont worry hpottinger :)
[20:18] <tdonohue> If I could, I'd start a "release team rotation" and ask everyone to be on the Release Team once every 2-4 years. But, I unfortunately don't have direct control over your time ;)
[20:19] <tdonohue> or maybe not "unfortunately" ;)
[20:20] <tdonohue> In any case...I guess you all probably get the point by now & I'll remind you again next week
[20:21] <hpottinger> tdonohue: I appreaciate you making this a priority. I *know* there are people out there who can't wait to volunteer. :-)
[20:21] <tdonohue> moving along, are there any 5.0 related topics anyone has to bring up? Any feature updates or features "waiting in the wings" that we should be expecting/preparing for?
[20:22] <hpottinger> @mire has their ORCID work, but I think we're waiting on a nod for Mirage2?
[20:22] <peterdietz> I think with mirage2, there's still some followup fixes, based on the discussion last week
[20:22] <tdonohue> Well, it's still possible to review the ORCID work, right? Even if it cannot be "merged" until Mirage 2?
[20:23] <hpottinger> tdonohue: that's a good point
[20:23] <KevinVdV> We are preparing the ORCID pull request & it should be reviewable without Mirage 2
[20:23] <robint> I have a wee Google Analytics reporting feature, but it is also dependent on Mirage2
[20:23] <mhwood> Thank you.
[20:23] <tdonohue> KevinVdV: sounds great! Any idea of the timeline of the Pull Request?
[20:23] <KevinVdV> Mirage 2 support will be added as a “bug fix patch” later on ;)
[20:23] * hpottinger gets giddy when the talk turns towards new features coming up for review.
[20:24] <KevinVdV> Well I hope to get the ORCID pull request fired this week (but not making any promises)
[20:24] <hpottinger> KevinVdV: noted. ;-)
[20:24] <tdonohue> robint: I saw your new ticket on recording GA events (DS-2088), and am looking forward to it
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-2088 ] - [DS-2088] Record bitstream downloads as Google Analytics events - DuraSpace JIRA
[20:24] <tdonohue> KevinVdV: sounds great! Even just knowing "next week or so" is good enough
[20:25] <robint> So is the Mirage2 PR ready to be merged once approved?
[20:25] <KevinVdV> Sadly I have a holliday coming up next week, so that is why I hope to have it THIS week ;)
[20:25] * aschweer (~andrea@129.73.69.111.dynamic.snap.net.nz) has joined #duraspace
[20:26] <mhwood> Terrible, having to go on holiday at a time like this. :-)
[20:27] <hpottinger> robint: I'd like to look at that GA code, have a vague idea for adding something else missing from GA tracking
[20:27] <tdonohue> robint: to answer your question...Mirage2 was getting positive reviews last week. Seems like it just needs a final quick vote once the updates are made (see Bram's last comment on DS-2052)
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-2052 ] - [DS-2052] Mirage 2 Responsive theme for the XMLUI - DuraSpace JIRA
[20:27] <robint> I'll email you hpottinger
[20:28] <robint> Ah ok, thanks tdonohue
[20:28] <tdonohue> Any other features that folks are prepping for 5.0?
[20:30] <KevinVdV> @mire is also preparing a more advanced solution for metadata for all building on the work started by mark wood
[20:31] <tdonohue> KevinVdV is that aimed for 5.0?
[20:31] <KevinVdV> It is
[20:31] <tdonohue> Any possible dates set for it yet? or is it still in flux?
[20:31] <tdonohue> (Just curious cause it has the possibility to affect other contributions, obviously)
[20:32] <KevinVdV> Hopefully a pull request either this week or in 2 weeks (due to my vacation ;))
[20:32] <mhwood> That would be very nice.
[20:32] <tdonohue> Oh, excellent again!
[20:32] <tdonohue> "Metadata for All" was on our 'wish list' for 5.0, so great to hear it's in the works...the "wish list": https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-ConceptualIdeas/Proposals
[20:33] <kompewter> [ DSpace Release 5.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status#DSpaceRelease5.0Status-ConceptualIdeas/Proposals
[20:33] <peterdietz> I've got the BatchImport through UI, thats got a PR. And I've been prototyping with dynamic configs. i.e. you can alter the running config of dspace, through UI, but I'm hitting obstacles
[20:34] <mhwood> Anything we can help with?
[20:35] <tdonohue> peterdietz... should mark DS-1641 for 5.0 and "needs code review" then? Is that Batch Import PR ready to go?
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-1641 ] - [DS-1641] Perform Batch Imports from Administrative UI - DuraSpace JIRA
[20:35] <tdonohue> "should we mark"
[20:35] <hpottinger> maybe we should do a "feature branch" of dynamic configs, if more cooks will help?
[20:36] <hpottinger> +1 needs code review for ds-1641, and fix for 5
[20:36] <kompewter> [ https://jira.duraspace.org/browse/ds-1641 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[20:36] <hpottinger> woah, I broke kompewter
[20:37] <tdonohue> If there's a good "plan"/examples on dynamic configs, I might be able to pull away some time here and there to help tackle parts. So, yes, Dynamic Configs work could be done in a shared "feature branch" if we have a good plan in place
[20:37] <peterdietz> it can be marked for 5. Its pretty stable, though, we haven't deployed it to production clients yet.
[20:38] <peterdietz> But, I've been testing recent batch loads from clients, and its is working pretty stably
[20:38] <peterdietz> My dynamic-configs branch is online at: https://github.com/peterdietz/DSpace/tree/dynamic-config
[20:38] <kompewter> [ peterdietz/DSpace at dynamic-config · GitHub ] - https://github.com/peterdietz/DSpace/tree/dynamic-config
[20:38] <tdonohue> peterdietz: ok, done. I've marked 1641 for 5.0, added you as "assigned" (since you wrote the code) and marked "code review needed"
[20:38] <peterdietz> Its based off of the lyncode approach, but I've been refactoring it, and adding to it
[20:40] <tdonohue> peterdietz: so, it's based off of DSPR#61?
[20:40] <mhwood> Dynamic config is going to ripple through a lot of code. It requires new thinking about how one handles configuration data: fetch it when you need it, don't cache locally.
[20:40] <kompewter> [ https://github.com/DSpace/DSpace/pull/61 ] - Enabling Dynamic DSpace Configuration Manager by lyncodev
[20:42] <peterdietz> yeah, I checked out his code, and then worked from there
[20:42] <mhwood> The code using ConfigurationService is probably following the "new" pattern pretty well, but code using ConfigurationManager will need close inspection.
[20:43] <hpottinger> (I think mhwood just volunteered to review)
[20:45] <peterdietz> I've made all method calls in ConfigurationManager end up calling config = new DSpace().getConfigurationService; config.getProp(...)
[20:45] <mdiggory> peterdietz: glad to hear its leveraging the COnfigurationService.
[20:45] <mdiggory> peterdietz: that would be an ideal design...
[20:45] <peterdietz> heh, mdiggory the first thing I did was re-read the Tao of Services.. I should get a leather bound edition of that
[20:45] <mhwood> Yay, DS-1390 will soon be obsolete.
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-1390 ] - [DS-1390] DSpace has too many configurations - DuraSpace JIRA
[20:46] <mdiggory> Theres are other places I've taken the same approach with "Static Managers"
[20:47] <mhwood> Once ConfigurationManager is all wrappers, we can @Deprecated it and the compiler or IDE will tell us where to look for work to do.
[20:47] <hpottinger> oh, yay, more deprecated classes :-)
[20:47] <peterdietz> I've got a youtube screencast of me poking around at it.. https://www.youtube.com/watch?v=iPZDbRBVxSo
[20:48] <kompewter> [ Dynamic Configuration in DSpace, command line - YouTube ] - https://www.youtube.com/watch?v=iPZDbRBVxSo
[20:48] <tdonohue> sounds like some much needed, excellent work, peterdietz
[20:48] <peterdietz> I can't stand hearing my voice anymore....
[20:48] <aschweer> people with local developments might need a big heads up on the dynamic configuration thing too
[20:48] <peterdietz> yeah. if this adventure (dynamic config) doesn't get in, then I'll just cherry-pick the other fixes in
[20:49] <mhwood> Maybe break the work down that way anyway. Anything that can stand alone and improve the product should go ahead and move in when it's thought to be working.
[20:49] <robint> peterdietz: Cool video, I think it also features your family in the background :)
[20:49] <mhwood> More small merges, fewer big ones, earlier exposure.
[20:50] <peterdietz> yeah. I have a nasty habit of recording screencasts when we're in the car.. VW is very sound proof. The kids are usually quiet. And we've been doing 7 hour drives lately
[20:51] <peterdietz> ...plus the new MBP battery lasts an entire day
[20:51] <robint> A mixed blessing
[20:52] <tdonohue> The number of things we have "in mention" here for 5.0 is astounding...a lot of things that have been mentioned off & on for some time (both by Devs & RepoMgrs): Bulk Upload via UI, Metadata For All, Dynamic Configs, tracking file downloads in Google Analytics, not to mention a cleaner UI in Mirage v2
[20:52] <robint> The battery that is!
[20:53] <hpottinger> It's a pretty exciting release, 'tis true.
[20:54] <peterdietz> So, I've just dug into my code, and I've discovered that maybe I'm not as far behind as I thought I was. i.e. booting xmlui says:
[20:54] <peterdietz> org.dspace.browse.BrowseException: Browse Index configuration is not valid: webui.browse.index.2 = author:metadata:dc.contributor.*
[20:55] <peterdietz> but the config says:
[20:55] <peterdietz> peterdietz:peterDSpace peterdietz$ /dspace/bin/dspace config -g -p webui.browse.index.2
[20:55] <peterdietz> ConfigClass: class org.dspace.servicemanager.config.DSpaceDynamicConfigurationService
[20:55] <peterdietz> GET property:[webui.browse.index.2] == [author:metadata:dc.contributor.*, dc.creator:text]
[20:55] <peterdietz> webui.browse.index.2 = author:metadata:dc.contributor.*,dc.creator:text
[20:55] <tdonohue> We are at only about 5 mins to go. I think we've done a good amount of "info sharing here" on 5.0 hopeful features, which is excellent
[20:56] <mhwood> So, as aschweer noted, maybe time to mention dynamic config. and its implications for local code on -tech?
[20:56] <peterdietz> The issue is that it is treating this as multiple value's for the config property.. And I don't think we allow for splittable properties, so treat the comma as a literal
[20:57] <robint> Time to head off, cheers all
[20:58] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) Quit (Quit: Page closed)
[20:58] <tdonohue> We don't have much time left to go here, so I'm going to avoid calling any further topics for today
[20:58] <peterdietz> I'm not sure I see all of the implications of the dynamic configs, other than its probably going to break in random places, depending on things holding on to values..
[20:58] <mhwood> That's quite enough, though.
[20:58] <peterdietz> But, we use caches that way, so, its likely to just create a million endless things to chase down...
[20:58] <aschweer> just thinking of my own local code, it means I need to know that I'll need extra dev cycles when doing the upgrade to make sure I don't hold on to config values
[20:59] <aschweer> so I guess I'm saying, giving people a heads-up (and this may not need to be now already, just mention it prominently along with new features) lets them make better estimates of how long it might take them to do the upgrade
[20:59] <peterdietz> Right. I think right now this isn't DB-driven configs.. That has complicated implications. I'll follow lyncodes route, where it writes to the config files after every config change
[21:01] <aschweer> but ConfigurationManager at the moment doesn't read the config file every time you ask it for a value, right? it reads the config once on start-up
[21:01] <peterdietz> I've got no promises that dynamic configs make it to dspace 5. Would be very nice, but I've got my fingers crossed that someone will be telling me to go on holiday
[21:02] <peterdietz> correct, once on startup. I also am not sure if that's once per the kernel, or once per each webapp..
[21:02] * tdonohue notes that there will be no more topics for today. I'm not going to stop this discussion, but please feel free to filter out as you need to. The "official" part of the meeting is closed...now transitioning to informal chat.
[21:03] <aschweer> I need to go to work. bye everyone
[21:03] * aschweer (~andrea@129.73.69.111.dynamic.snap.net.nz) Quit (Quit: leaving)
[21:05] <mhwood> I have to go too. 'bye all.
[21:05] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:06] <tdonohue> Informal note for anyone still around: I'm still looking for feedback on the proposal/idea to also support DSpace Q&A on StackOverflow.com...if anyone has thoughts or even just +1/0/-1 informal votes, send them my way.
[21:06] <mdiggory> peterdietz: you may also need to look into the ServiceManager a little bit too
[21:06] <hpottinger> +1 stackoverflow
[21:06] <tdonohue> (In general most folks that I've heard from have been supportive of StackOverflow idea...but I've only really heard from <5 folks directly)
[21:06] * terryb (~anonymous@162.244.138.212) Quit (Ping timeout: 245 seconds)
[21:07] <mdiggory> I believe that the Spring Application Context is reading the ConfigurationService at the point of initialization and may inject its values via a PropertyPlaceholder
[21:07] <KevinVdV> Needs to run, see you all in 2 weeks !
[21:07] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) Quit (Quit: KevinVdV)
[21:07] <mdiggory> This is why DSpaceConfigutationService is created outside the Spring Application Context
[21:09] <hpottinger> maybe peterdietz and mdiggory do a Google Hangout and sort out dynamic config?
[21:10] <peterdietz> I'm still a bit confused by what all spring is doing
[21:11] <peterdietz> (i forgot, I have a git stash that has a lot of my config work, so the latest commit isn't everything, but it was my latest working checkpoint)
[21:12] * vtkeithg (~vtkeithg@vtkeithg.lib.vt.edu) has left #duraspace
[21:19] * kohts (5b4e6f33@gateway/web/freenode/ip.91.78.111.51) Quit ()
[21:23] <peterdietz> I've just added my git stash as a commit to a branch called dynamic-config-wip, and this is even less stable than the other branch(dynamic-config), but this feels like the direction I should be going, but something springy is likely not correct: https://github.com/peterdietz/DSpace/tree/dynamic-config-wip
[21:23] <kompewter> [ peterdietz/DSpace at dynamic-config-wip · GitHub ] - https://github.com/peterdietz/DSpace/tree/dynamic-config-wip
[21:23] <peterdietz> heading out
[21:25] <hpottinger> I just tagged DS-1562 as "low hanging fruit" since there's JSPUI code from which someone might copy
[21:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1562 ] - [DS-1562] Using HTML5 for File Upload in XMLUI - DuraSpace JIRA
[21:27] <mdiggory> hpottinger: peterdietz a google hangout would be useful, time is hard to find for face2face..
[21:30] <hpottinger> I don't need to be on the call, but, I really think a jam session between you two would be pretty helpful
[21:40] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[22:20] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[22:30] * monikam_ (~Monika_Me@monika.Princeton.EDU) Quit (Quit: Leaving.)
[23:31] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Ping timeout: 255 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.