Timestamps are in GMT/BST.
[3:00] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 264 seconds)
[3:04] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[6:30] -hitchcock.freenode.net- *** Looking up your hostname...
[6:30] -hitchcock.freenode.net- *** Checking Ident
[6:30] -hitchcock.freenode.net- *** Found your hostname
[6:30] -hitchcock.freenode.net- *** No Ident response
[6:31] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:31] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:31] * 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:26] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[14:16] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[14:56] <tdonohue> REMINDER: DSpace Developers meeting starts in ~5mins (top of the hour) https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-03
[14:56] <kompewter> [ DevMtg 2015-06-03 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-03
[14:57] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[15:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Mtg. Agenda is at https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-03
[15:00] <kompewter> [ DevMtg 2015-06-03 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-03
[15:01] <tdonohue> First and foremost, in case anyone has forgotten (doubtful), next week (June 8-11) is the Open Repositories conference in Indianapolis. So, I'm hoping to see many of you there!
[15:02] <tdonohue> As noted via email, the agenda for our Developer/DCAT meeting on Monday at 1:30pm is now posted: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-08+-+OR15+Meeting
[15:02] <kompewter> [ DevMtg 2015-06-08 - OR15 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-08+-+OR15+Meeting
[15:02] <pbecker> tdonohue: so next Wednesday there is no developer meeting. Right?
[15:03] <tdonohue> If you are attending that OR face-to-face meeting, I'd like to ask that you take some time prior to Monday to review the Strategic Plan & RoadMap documents (which we will be discussing during the meeting)
[15:03] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+2015-18+Strategic+Plan and https://wiki.duraspace.org/display/DSPACE/RoadMap
[15:03] <kompewter> [ DSpace 2015-18 Strategic Plan - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+2015-18+Strategic+Plan
[15:03] <kompewter> [ RoadMap - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/RoadMap
[15:04] <tdonohue> pbecker: that is correct, there will be no IRC developers meeting next week (on June 10). The conference will be going on that time
[15:05] <tdonohue> I will have someone take notes for the face-to-face meeting on Monday, June 8. So, we'll try to get those posted ASAP for anyone unable to attend. Our next IRC based meeting (after this one) will be on Weds, June 17th at 15UTC
[15:06] <tdonohue> Any other questions or comments regarding Open Repositories, etc?
[15:06] <pbecker> tdonohue: in one of the last developer meetings you said, that you want to discuss about the early developer meetings at or15.
[15:06] <pbecker> Can we perhaps talk about them here before, as I won't be able to make it to OR15.
[15:06] <tdonohue> pbecker: yea, that was mentioned. I'm not sure how much time we'll have for that discussion, but it may come up.
[15:07] <tdonohue> pbecker: sure, we can talk about it a bit today too. I did get your note that these early (15UTC) meetings are more convenient for you than the later (20UTC) ones
[15:08] <pbecker> The later once happen between 10pm and 11pm of my local time.
[15:08] <tdonohue> To be clear here, my intention is NOT necessarily to cancel the "early meetings". I'm more wanting to figure out how we can get more Europeans to attend. We initially wanted the 15UTC meetings to be more convenient for Europeans, and yet it seems like few of them (except for you pbecker & helix84) take much advantage of these early meetings.
[15:09] <pbecker> While I see that there are not so many European developer attending the early meetings as expected, I don't see so much more attendences in the log of the late meetings.
[15:09] <pbecker> Glad to hear that.
[15:10] <tdonohue> pbecker: that statement is true overall. Though it's strange to me that sometimes we actually have a few Europeans (UK folks mostly) who tend to attend 20UTC rather than 15UTC.
[15:10] <pbecker> I just was afraid that the early meetings could get canceled. ;-)
[15:10] <pbecker> I see.
[15:11] <tdonohue> Overall, I still think we need to have two separate times for these meetings. As something around 20UTC would be more convenient for Western USA + folks in New Zealand. Something around 15UTC would be more convenient for folks in Europe.
[15:11] <tdonohue> In my mind, it's really about trying to figure out whether 15UTC and 20UTC are the *best* times still...or if we move one or more of those by an hour
[15:12] <tdonohue> And, also trying to find a way to get more folks to attend these meetings *in general*. We tend to mostly get the same small group, and it'd be nice to expand that :)
[15:13] <tdonohue> Any other thoughts on these meeting times from anyone?
[15:14] <tdonohue> Or the meeting structure in general for that matter? I'm open to suggestions on how we host these meetings in general, honestly, and it probably is worth our reviewing our processes again to see if we'd like to make updates/changes
[15:15] <pbecker> tdonohue: did you ping helix84, mhwood, peterdietz and others around here?
[15:15] <peterdietz> hi
[15:15] <mhwood> hi
[15:16] <tdonohue> pbecker: thanks :) I forgot to do the normal "ping" of normal folks
[15:16] <mhwood> It's been a long time since anyone described me as "normal".
[15:16] <tdonohue> haha
[15:17] <tdonohue> Ok, any other thoughts or questions on Open Repositories stuff? (since we went off on a bit of a side discussion there)
[15:18] <tdonohue> Hearing none...we can move along
[15:18] <peterdietz> I'm guessing that OR discussions will likely center on how to keep up the momentum on DSpace development (I think its continued to keep on going strong). And then to follow up on the goals of lean / primary UI / etc
[15:18] <tdonohue> I'll admit, our agenda is a bit "light" today, mostly cause I'm busy prepping for OR this week. My only other item for today was to touch base on 6.0 stuff
[15:19] <pbecker> tdonohue: perhaps I can jump in then?
[15:19] <tdonohue> peterdietz: yes, there's an agenda posted now for the Face-to-face meeting. The primary discussions will revolve around the Strategic Plan & RoadMap (please review both when you get the chance), and how we move both forward into action...i.e. what we do in 6.0, how we start to work towards Roadmap goals for 7.0, etc
[15:20] <tdonohue> peterdietz: OR meeting agenda is up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-08+-+OR15+Meeting
[15:20] <kompewter> [ DevMtg 2015-06-08 - OR15 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-08+-+OR15+Meeting
[15:20] <tdonohue> pbecker. go ahead
[15:20] <pbecker> I want to bring back a topic we discussed 4 weeks ago: versioning. mhwood was so kind to review DS-2497.
[15:21] <kompewter> [ https://jira.duraspace.org/browse/DS-2497 ] - [DS-2497] DSpace should keep the version number persistent - DuraSpace JIRA
[15:21] <pbecker> Just to give you the follow up: I produced several PRs around versioning.
[15:21] <pbecker> And I would like to merge them asap, because I don't want to have to rebase all of them.
[15:21] <pbecker> DS-2497 is just one of several PRs (DS-1348, DS-1349, ...)
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2497 ] - [DS-2497] DSpace should keep the version number persistent - DuraSpace JIRA
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1348 ] - [DS-1348] Item level versioning breaks persistence and lacks meta information - DuraSpace JIRA
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1349 ] - [DS-1349] Item level versioning exposes personal data (name and email of submitter, versioning creator) - DuraSpace JIRA
[15:22] <pbecker> I know that this is a matter we would love to see @mire reviewing the code as they initially wrote it. But I want to move forward and they did not react on pinging them in Jira or in the developer logs.
[15:23] <tdonohue> pbecker: could you get these listed on our 6.0 planning page? They should be in the "Wishlist" table (even though I know they are already basically "done" and just need review): https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[15:23] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[15:24] <pbecker> (just finding the other ticket numbers: DS-1814, DS-2490)
[15:24] <kompewter> [ https://jira.duraspace.org/browse/DS-1814 ] - [DS-1814] Allow submitter to create a new version of an item - DuraSpace JIRA
[15:24] <kompewter> [ https://jira.duraspace.org/browse/DS-2490 ] - [DS-2490] Add DOI support to Item Level Versioning - DuraSpace JIRA
[15:24] <tdonohue> The reality here is that, I'm not gonna have time to dig into these prior to the conference. But, I *can* pester @mire and others to review these while I'm at the conference
[15:25] <tdonohue> So, since we will be making time to discuss 6.0 features/plans at the conference, I don't want to forget about mentioning these, and getting others to help out
[15:25] <pbecker> tdonohue: that would be great. I really don't want to be in the situation we had last year with RDF (were @mire and me were working on the same feature and had to decide for one code).
[15:25] <pbecker> So I'll add them to the 6.0 Release Status page.
[15:25] <pbecker> and thanks in advance for bringing it up at or15.
[15:26] <peterdietz> (one of the sites we host is still going to use the oceanlink RDF code, so I'll have to figure out how to shoe-horn in two RDF impls, or see if @mire has a solution)
[15:26] <tdonohue> +1 I don't want to end up in that scenario either. Plus, this work (at least at a glance) seems to align well with the RoadMap (i.e. enhancing versioning in general is listed on there, and it'd be nice to see that happen immediately in 6.0)
[15:28] <peterdietz> Yeah, probably best to get reviews on the versioning PR's, and merge them. So that we're not spending too much effort than neccessary on issues
[15:28] <pbecker> peterdietz: I'm bagging for reviews since weeks. ;-)
[15:29] <tdonohue> pbecker: as a sidenote to the RDF stuff, I will also note that in the RoadMap I've also specifically mentioned finding more ways to "integrate or utilize" the RDF interface for DSpace in order to define richer relationships between objects, etc. That's something listed as a possibility for 7.0 (in 2016). Though I'd mention it though since it might be of interest
[15:29] <tdonohue> It's not well defined on the Roadmap yet though, just mentioned under the feature "Relationships between objects" :)
[15:29] <pbecker> tdonohue: yes thanks. I look on the hole list some weeks ago, and will do again soon.
[15:30] <pbecker> in the 6.0 whishlist there is a priority column. Is there any criteria for that column?
[15:31] <tdonohue> +1 to reviewing PRs more rapidly. We might want to rethink our processes with regards to PRs, just to see if there's a way to respond more quickly, and merge more rapidly (when it makes sense)
[15:32] <tdonohue> pbecker: good question about the priority. The "criteria" is mainly how well I think it aligns with the RoadMap priorities, etc. In the case of this Versioning work, it's probably High priority
[15:32] <tdonohue> (so, the prioritization is really my own thoughts right now. Folks can feel free to disagree or argue against my prioritization though, and we can bump things up or down)
[15:33] <peterdietz> My only thoughts on the versioning would be, does this introduce any new issues (probably not). And since I've been touching the asset store. The bitstore cleanup code has a special check for versioned items.. So that's something that I would have to verify still works
[15:34] <pbecker> tdonohue: I just saw the other priorities (Removing old stuff, introducing uuids and so on) which let me give versioning a "medium" priority. but feel free to bump it if you think so.
[15:34] <tdonohue> peterdietz: yep, agreed. We are looking for more testers / reviewers of this code in general :)
[15:34] <pbecker> peterdietz: we are changing some behavior (e.g. keeping version numbers stable if you delete the newest version, ...).
[15:34] <tdonohue> pbecker: just get it listed for now, and we can reprioritize things later (perhaps even based on OR discussions or at OR)
[15:35] <pbecker> +1
[15:37] <tdonohue> So, stepping back to our agenda. As I mentioned a while back, the agenda is "light" today. I was mostly just wanting to touch base some more on 6.0. Any other features folks are working on for 6.0? Anyone interested in volunteering for something listed on the "Wish list"? https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[15:37] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[15:38] <tdonohue> Regarding 6.0, we also are still looking for Release Team members! If you are even (vaguely) interested, please get in touch, and I can give more info on what this means, etc
[15:39] <peterdietz> If a refactor of ES is on the list, then my name will eventually have to touch it
[15:40] <peterdietz> I don't see how you gain anything by removing ES though.. It never gets loaded unless you explicit enable it in several places though. And it seems like you would want someone to breath new life into SOLR reports before yanking it out of the core
[15:40] <tdonohue> ES is on the "wish list" yes, and it's also listed on the RoadMap as something we need to deal with. Our Strategic Plan is to avoid duplicative functions *out-of-the-box*, but allow for add-on modules. So, in my mind, ES Stats eventually needs to be refactored into an "add-on"
[15:40] <tdonohue> But, "eventually" may not be the highest priority for 6.0. It would become a higher priority likely for 7.0 though
[15:41] <peterdietz> I guess I need further clarification on this goal. Is this just interface + multiple implementations? Or some other thing
[15:41] <peterdietz> i.e. properly refactored pieces are fine / encouraged, but improperly wedged things are not
[15:41] <peterdietz> i.e. I would fight to introduce an S3 bitstream storage implementation
[15:42] <peterdietz> ...with a proper interface/impl
[15:42] <tdonohue> It's about avoiding multiple implementations "out of the box". There's no reason to ship all Dspace releases with all the code/dependencies for two separate Statistical engines. So, currently in DSpace 5, ES (as a dependency) is included in all installs by default, even if you aren't using it.
[15:43] <peterdietz> I see other things like DSpace Services ConfigurationService vs ConfigurationManager an area that is more important to clean up the duplication
[15:43] <tdonohue> In the future, DSpace should have a "default" Stats engine. But, you'd have the option to say, I'd rather install this other module and use it
[15:43] <mhwood> peterdietz: oh, yeah, I need to get back on that one.
[15:43] <tdonohue> Yea, we should list that ConfigService vs ConfigManager on the 6.0 page. I agree that'd be higher priority to me as well
[15:44] <peterdietz> ConfigService doesn't support loading configs in modules, so I don't like that one
[15:44] <tdonohue> The ES refactoring to me is not highest priority for 6.0. But, it is something that I think *must* be done. If it doesn't happen in 6.0, it's OK. But, it probably should happen for 7.0
[15:44] <pbecker> tdonohue: I totally understand the reason to make such a Road Map. But every time we discuss it we come back to the point that we cannot tell volunteers which feature they should develop and that we want to stay open for ideas and contribution beside the roadmap. I think we should stay open for duplicating features to move on to new techniques (g.e. the way we moved from lucene to solr).
[15:46] <peterdietz> Isn't our solr implementation dependent on having DSpace maintain some hacks of solr? i.e. org.apache.solor.handler.extraction.ExtractingParams
[15:46] <tdonohue> pbecker: I agree as long as those "duplicate features" are properly refactored. This is why the RoadMap lists creating a "Module Framework & Registry" as high priority for 7.0. We want a more specific module framework (for add-ons) so that duplicate features can be built (and made *optional* to install)
[15:47] <mhwood> We should look and see whether Solr 5 takes care of the stuff we hacked.
[15:47] <tdonohue> What I don't agree with is the current route of sticking a bunch of duplicative code into the "dspace-api". I think we need to streamline what is in "dspace-api" and move more things to a "module framework" (yet to be defined)
[15:47] <pbecker> But if you design something as add-on you will have to investigate time into it when you want to make it the new default.
[15:48] <pbecker> I would agree, if we would move *all* of DSpace to a more module like way.
[15:48] <pbecker> But I don't like to seperate DSpace into core and add-ons.
[15:48] * pbecker will have to leave in 6 minutes and is sorry about that.
[15:49] <peterdietz> There should be an end goal in this design, other than just causing pain. i.e. Wordpress lets you click buttons, and modules can be enabled/disabled/configured. Would this end-goal for DSpace of moving the other-than-first implementation of features outside allow us to have a way to enable through through button clicking? Or just painful maven rebuilding
[15:49] <peterdietz> processes
[15:49] <mhwood> Does it make sense to speak of refactoring text indexing altogether? That is: all use of Solr and/or ES becomes pluggable behind a "text indexing" provider interface. Event storage becomes pluggable behind another interface, and some event storage and statistical analysis plugins may make use of the text indexing service. Is that too huge to contemplate all at once? (I haven't looked into the ramifications of this at all, just brainstorming.)
[15:49] <tdonohue> +1 pbecker: I'm actually talking about moving DSpace to be more modular in general. I'm just taking smaller steps to get there. So, my vision would be that "out-of-the-box" DSpace would include some "Default modules". But you could choose to uninstall some (e.g. Solr Stats) and instead use others (e.g. ES Stats).
[15:50] <tdonohue> I'm merely moving there in "stages"...by refactoring first the duplicative stuff out of dspace-api. Moving it into modules. Then finding ways to move much of the other stuff into modules as well to streamline dspace-api further. How it exactly plays out we'll need to see...maybe we can do it all at once
[15:51] <pbecker> tdonohue: I think it would help to speak of modules and not of add-ons. so it becomes more clear that we don't want to separate in core and add-ons, but create modules (nevertheless if they are delivered by default or not).
[15:52] <tdonohue> This is all why refactoring ES Stats is not highest priority to me yet. First, we need a better definition for our "DSpace Module Framework" (how these modules are created, managed, installed, upgraded). Then we start moving things into being modules
[15:52] <mhwood> So some modules are add-ons and some modules "come in the box"?
[15:52] <tdonohue> pbecker: good point on my terminology :)
[15:52] <mhwood> Some modules are mandatory: you must pick one. Others are optional. Yes?
[15:53] <tdonohue> modules are all equal. Yes, my vision would be that some are "default out-of-the-box" (i.e. the ones we think most folks will want to use by default & that make Dspace easy to get started with. Some may be mandatory, others may be "recommended"). Others are available to install if you want them
[15:54] <pbecker> tdonohue: sounds better. ;-)
[15:54] <tdonohue> So, in the case of Stats...We'd likely have a "recommended" Stats module. But, in reality, DSpace doesn't *require* that you use Stats. So, you could choose to just not even use any Stats modules, or choose to use a different one
[15:54] * pbecker added versioning to DSpace Release 6.0 Status.
[15:54] <pbecker> I have to run. Wish you a great OR15!
[15:55] <tdonohue> thanks pbecker! bye
[15:55] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[15:55] <tdonohue> I also have to run here shortly. There's a DSpace Steering Mtg in 5mins (so I'll miss the JIRA backlog hour)
[15:55] * kohts (~kohts@195.68.180.4) has joined #duraspace
[15:56] <tdonohue> I'll try and take this "modules" discussion and synthesize it down into some ideas/concepts and post them into the RoadMap feature notes. It seems like we may have gotten somewhere useful here (at least in terms of terminology, etc)
[15:57] <tdonohue> Beyond that, I'm not going to bring up any further topics here (since I do have to leave). But, I look forward to seeing some of you next week!
[15:57] <peterdietz> I'm afraid I'm not entirely behind the purge of secondary implementations. The DSpace documentation typically says, change this config, and the optional version starts working. Plucking everything out, changes that advice to change some poms, rebuild everything, redeploy, ...
[15:57] <tdonohue> The formal meeting is closed, but feel free to having additional discussions as needed.... I'll touch back in later.
[15:58] <peterdietz> So, if there was a module-manager that makes it easier to work with, then I would be behind it
[15:58] <tdonohue> peterdietz: secondary implementations "bloat" our install (add things to the API you don't need, and add dependencies you really don't need). E.g. why are we installing ES as a (rather large) dependency via Maven for all DSpace 5 sites? And, yea, my hope would be that we build a module manager to help clean this up :)
[15:59] * mhwood has nefarious plans to make Solr and Handle "even more modular" by making it possible to jack DSpace into entirely separate indexing and Handle servers that may already be there doing other work. Just tell DSpace where the services are, and don't install new ones.
[15:59] <mhwood> No code yet -- not even a sketch.
[17:00] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) has joined #duraspace
[17:25] * kohts (~kohts@195.68.180.4) has left #duraspace
[21:10] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:16] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:43] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[23:00] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.