Timestamps are in GMT/BST.
[1:03] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[6:16] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[6:38] -sendak.freenode.net- *** Looking up your hostname...
[6:38] -sendak.freenode.net- *** Checking Ident
[6:38] -sendak.freenode.net- *** Found your hostname
[6:38] -sendak.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:52] * eddies (~eddies@cm21.eta98.maxonline.com.sg) has joined #duraspace
[7:52] * eddies (~eddies@cm21.eta98.maxonline.com.sg) Quit (Changing host)
[7:52] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:30] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:44] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[15:10] * hpottinger (~hpottinge@74-84-98-51.client.mchsi.com) has joined #duraspace
[15:45] * hpottinger (~hpottinge@74-84-98-51.client.mchsi.com) Quit (Quit: Later, taterz!)
[17:20] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[17:46] * fasseg (~ruckus@91.112.215.154) has joined #duraspace
[18:42] * bram-atmire (~bram@94-225-35-170.access.telenet.be) has joined #duraspace
[18:44] <bram-atmire> hi
[18:55] * RichardJones (~richard@188-222-5-105.zone13.bethere.co.uk) has joined #duraspace
[19:56] <tdonohue> Reminder, DSpace Devel Mtg starts at top of the hour (~3 mins).
[19:57] * kstamatis_ (5b8c1947@gateway/web/freenode/ip.91.140.25.71) has joined #duraspace
[20:01] <tdonohue> Hi all, and welcome to our weekly DSpace Devel Mtg. Today we have an informal agenda (mostly cause I hadn't had a chance to write one up today, my apologies).
[20:01] <tdonohue> However, the topics I believe we should cover are:
[20:01] <tdonohue> 1) Updates on the JSPUI security issue status & working towards release & notification of public.
[20:02] * l_a_p (~chatzilla@31.189.204.32) has joined #duraspace
[20:02] <tdonohue> 2) DSpace Developers OR13 Meeting agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting
[20:02] <kompewter> [ DevMtg 2013-07-08 - OR13 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting
[20:02] <tdonohue> 3) if we have time, we are free to discuss other topics (4.0, or whatever else is on your minds)
[20:03] <PeterDietz> We also have a topic about swordv2, and we have RichardJones here today
[20:03] <hpottinger> I believe RichardJones has an agenda item
[20:03] <RichardJones> hi
[20:04] <RichardJones> if there's time, I'd be interested in talking a bit about how to maintain 3rd party modules as part of DSpace - in particular swordv2 and to a lesser extend resourcesync
[20:04] <RichardJones> one of which I'd like to get into the main release (the new version of swordv2) but the other which is experimental, so doesn't belong in the main codebase
[20:05] <tdonohue> that sounds reasonable to add as well, RichardJones. I wonder though if we should start off with the security issue discussion however (as I see that as top priority)? Just want to make sure we keep on top of getting that done
[20:05] <RichardJones> yup, I'm happy to fit into item (3) :)
[20:06] <tdonohue> ok. So, kicking things off #1 : I just wanted to update folks on the JSPUI Security issue (again, reminder...please don't add any specifics to this discussion -- we are being logged and this issue is still being resolved)
[20:07] <kstamatis_> Hardy seems to have done great job regarding the security issue
[20:07] <kstamatis_> Didn't have time to test it, but I would do so today or tommorow
[20:07] <tdonohue> yes, hpottinger has a proposed fix & has done a great job. The fix currently is only ready/tested for 3.x (so far)
[20:08] <hpottinger> ah, shucks, I had help :-) mhwood in particular pointed me towards the improved security libraries
[20:08] <kstamatis_> I could port it to previous versions if we are sure that this is the optimal solution
[20:08] <tdonohue> As of (literally) a few minutes ago, we now have the ability to release a security release of 1.7.x & 1.8.x (per our policies). I've been doing some cleanup of our old branches to ensure they build properly in GitHub & Maven 3 (See DS-1587).
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1587 ] - [#DS-1587] Update 1.7.x and 1.8.x branches for Git/GitHub - DuraSpace JIRA
[20:09] <tdonohue> As of a moment ago, DS-1587 seems to be "fixed" (or at least it's fixed for both hpottinger & I)
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1587 ] - [#DS-1587] Update 1.7.x and 1.8.x branches for Git/GitHub - DuraSpace JIRA
[20:09] <hpottinger> tdonohue is correct, I can run mvn install for both 1.7 and 1.8 branches
[20:10] <tdonohue> We needed Ds-1587 to get resolved in order to be able to "backport" hardy's work. So, now someone can backport Hardy's JSPUI fix to 1.7.x and 1.8.x JSPUIs
[20:10] <tdonohue> and it sounds like kstamatis_ just volunteered to help with the backport to 1.7.x and 1.8.x?
[20:10] <kstamatis_> true
[20:11] <hpottinger> OR13 is next week, fixing bugs is like buying yourself beer
[20:11] <tdonohue> thanks kstamatis_!
[20:11] <tdonohue> OR13 is actually in two weeks, though it feels like next week :)
[20:11] <hpottinger> oh, correct, I leave for PEI this weekend
[20:12] <tdonohue> So, kstamatis_ can you let us know (via dspace-commit or IRC) once you have a successful backport ready to go?
[20:12] <kstamatis_> sure
[20:13] <tdonohue> Once the backport is ready & tested...we will be performing a (nearly simultaneous) release of 1.7.3, 1.8.3, and 3.2 to fix this issue. Then we'll report it to the general public and encourage upgrading to one of those versions.
[20:14] <tdonohue> Any other questions/comments on this security issue topic? (Just want to be sure I'm not missing anything)
[20:15] <tdonohue> Ok, hearing none...we'll move on
[20:15] <tdonohue> (if anything comes up, feel free to send us all an email on dspace-commit!)
[20:15] <tdonohue> Next topic: OR13 DSpace Developers Mtg.
[20:16] <tdonohue> We've got a nice list of attendees (22 folks) and a good looking agenda list so far
[20:16] <tdonohue> agenda list: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting#DevMtg2013-07-08-OR13Meeting-PossibleAgendaDiscussionTopics
[20:16] <kompewter> [ DevMtg 2013-07-08 - OR13 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting#DevMtg2013-07-08-OR13Meeting-PossibleAgendaDiscussionTopics
[20:17] <tdonohue> I think we have a "full enough" agenda (for our 4 hours). But if anyone has any last topics, please feel free to forward my way
[20:17] * bram-atmire can't wait
[20:17] <tdonohue> I will be working to "finalize" the agenda this week & next week.
[20:18] <PeterDietz> i need to add myself to that list
[20:18] <tdonohue> Also, if anyone would like to lead a particular discussion topic (looking towards hpottinger/mhwood around 4.0 topic?), let me know. I'd rather not be the only one talking at folks the entire time ;)
[20:18] <mhwood> Looking forward to building momentum on the metadata cleanup.
[20:19] <tdonohue> I'll look at getting a final agenda schedule posted (with some breaks) in the next week.
[20:19] <bram-atmire> Are there any decisions that need to be taken at OR?
[20:19] <tdonohue> One final note, regarding the "after meeting pub" that we all will go to...
[20:20] <tdonohue> I noticed there's a "Bar Bingo" that night. Not sure if we want to join that, or strike out on our own. But, we can all think about it: http://or2013.net/content/bar-bingo-monday-night
[20:20] <kompewter> [ Bar Bingo - Monday Night | OR2013 ] - http://or2013.net/content/bar-bingo-monday-night
[20:20] * ruebot is now known as bilbo_baggins
[20:20] * bilbo_baggins is now known as gollum
[20:20] * gollum is now known as ruebot
[20:20] <bram-atmire> Thinking back about 2 years ago in TX, where the discussion about the versioning eventually lead to the decision to call the next release 3.0 instead of 1.9 ? (or do I remember that incorrectly?)
[20:21] <tdonohue> bram-atmire: regarding decisions..it'd be nice to get a better picture of 4.0 (I feel like it's still very "undefined"). We are looking to get feedback on the initial DSpace 3-5 year Vision and proposed next steps (but that's just feedback/suggestions)
[20:21] <tdonohue> It'd be nice to figure out where the metadata cleanup discussion fits in (and like mhwood says, build momentum & get next steps)
[20:21] <hpottinger> bram-atmire: your memory is correct, that discussion/decision was in Austin
[20:22] <tdonohue> There are no specific decisions that I felt *need* to happen at OR13. But, if anyone else feels otherwise, please feel free to speak up. It would be nice to make progress / determine next steps on each of our agenda items though
[20:23] <hpottinger> it would be great to have a better picture of what 4.0 will look like, and in particular, who is on the RT. Right now it's mhwood and me.
[20:24] <tdonohue> yes, our 4.0 Release Team needs more members & the release itself needs better definition.
[20:25] <tdonohue> We also may want to add an agenda item (thinking out loud here) for determining what "big topics" need to be discussed in future DSpace Devel Mtgs (whether via IRC, or maybe via a Virtual Summit if needed)
[20:26] <tdonohue> I'm just looking at the fact that 4 hours is not much time overall, but hopefully we can make some headway in all these topics
[20:26] <bram-atmire> everyone's insights are usually so good, that it's easy to lose track
[20:27] <bram-atmire> if something can be formulated as some kind of decision process, it could be easier to channel focus, or to have people look into this prior to the meeting
[20:27] <bram-atmire> for example, the translationwiki stuff: it's been circulating, but it might be a good boost if the people at the meeting would formally all agree on the idea that such a move is a good one
[20:27] <tdonohue> bram-atmire: I agree. The only thing that seems like it could fit that bill though is the "DCAT proposal to improve metadata support"
[20:28] <tdonohue> oh, yea, that's fine too. If you want to specifically talk about that, we should add it to the agenda
[20:29] <bram-atmire> The DCAT proposal translates into several technical aspects, like metadata for all, locking down schema's, separating out admin schema vs standard dc vs local customizations
[20:29] <bram-atmire> and it's a pity that the DCAT presentation/panel about this is only later in the week
[20:29] <bram-atmire> one technical piece of the metadata stuff is mdiggory's vision here: https://wiki.duraspace.org/display/DSPACE/Proposal+For+Metadata+Enhancement
[20:29] <kompewter> [ Proposal For Metadata Enhancement - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Proposal+For+Metadata+Enhancement
[20:30] <bram-atmire> but although it overlaps with the DCAT work, it's not a 1-1 match
[20:30] <bram-atmire> anyway, just a very elaborate way for saying
[20:30] <bram-atmire> that it won't be a binary decision on whether the meeting backs the DCAT proposal or not
[20:31] <bram-atmire> but that's just my personal take on things how I see them right now, could be wrong
[20:31] <mhwood> More like several decisions: when and in what order.
[20:31] <bram-atmire> exactly
[20:32] <tdonohue> right...I was hoping to at least come to a few decisions around metadata (the "when and what order") or at least a general consensus that things seem to be moving in a "good direction". But, I agree it won't be a binary decision
[20:32] * bram-atmire apologises, got to go
[20:33] * bram-atmire (~bram@94-225-35-170.access.telenet.be) Quit (Quit: bram-atmire)
[20:34] <tdonohue> ok, so, shame bram had to leave. Does anyone else have any suggestions on this meeting agenda? This is obviously *our* meeting...so, we should decide together what topics we'd like to cover and whether there are areas we'd like to see a decision happen
[20:34] <PeterDietz> If you think we need some filler. A show&tell would be interesting to see what each person been working on. Maybe a lightning round (less than a full presentation length)
[20:35] <tdonohue> It does seem like a full agenda, but we could always postpone some discussions for *after OR13*, if there are more important topics
[20:35] <PeterDietz> I could talk about Elasticsearch / Statistics, REST API, dissemination interceptors for PDF
[20:36] <tdonohue> PeterDietz, as nice an idea as a lightning round is, I'm more worried about not having enough time to cover the topics we have... 4 hours is not very long..but if we had extra time, I'm willing!
[20:36] <hpottinger> show and tell may take over the meeting, but I like the idea, maybe incorporate it as part of introductions: who are you, where are you from, and what's the coolest thing you're working on right now?
[20:36] <hpottinger> and bring notebooks to the pub
[20:37] <tdonohue> yea, we could do something like that with the intro (so at least folks could meet up and talk later at the pub)
[20:37] <kstamatis_> even if this is not part of the agenda, it would be a good idea for the new committers to know who is working on what... so, if it is a good idea even if it doesn't fit in the agenda
[20:38] <tdonohue> yep, makes perfect sense
[20:38] <tdonohue> I suspect some of the "who is working on what" may end up coming out during discussion of 4.0 (e.g. "what are folks working on that may be ready for 4.0"), but we'll see
[20:39] <tdonohue> Ok. any other ideas / thoughts regarding the OR13 mtg? Please feel free to send me an email (or email dspace-commit) if there's a topic that comes to mind that you feel would be worth touching on
[20:41] <tdonohue> Ok. I think we're done with that topic now too. Which should bring us to #3 : RichardJones topic around SWORD / ResourceSync / third party module maintenance
[20:41] <RichardJones> maybe, pending a discussion here about third party modules, it would be interesting to see what others there think - am i in a unique position, or is it an itch that others need to scratch too
[20:41] <RichardJones> ah, yes
[20:41] <RichardJones> was typing while you were!
[20:41] <mhwood> Please expand a bit on "third party module".
[20:42] <RichardJones> ok, so the question has arisen because I'm currently in the situation where I have two modules for DSpace that I'm working on: SWORDv2 (https://github.com/swordapp/DSpaceSWORDv2) and ResourceSync (https://github.com/CottageLabs/DSpaceResourceSync)
[20:42] <RichardJones> one of them is a derivative of code in a fork of DSpace 1.8 with a load of enhancements (the swordv2 one)
[20:43] <tdonohue> ok
[20:43] <RichardJones> I'd like to contrib it back for 4.0, but haven't been able to do the relevant git kung-fu to separate the code that I wrote for the sword2 module from the other localisations I wrote for the project concerned in that same forked repo
[20:44] <RichardJones> so I've created this revision-history-less repo
[20:44] <RichardJones> (https://github.com/swordapp/DSpaceSWORDv2)
[20:44] <RichardJones> not sure what the real best thing to do with contributing it is, though, so looking for advice
[20:44] <mhwood> So that's why it doesn't seem to be a fork off of DSpace/dspace -- I'd wondered.
[20:44] <hpottinger> "derivative" means produced by "git filter-branch" ?
[20:45] <RichardJones> no, there's no git relationship at all between that code, and the original forked code
[20:45] <RichardJones> it is just "the same" code
[20:46] <RichardJones> I wanted to circulate it for people to play with independently of the project I developed it during (https://github.com/nye-duo/DSpace)
[20:46] <RichardJones> ok, so to give you the rest of the background
[20:46] <hpottinger> ah, OK, I've been doing something similar with git filter-branch and XMLUI themes, and have been using git submodules to pull the code back in
[20:46] <RichardJones> I have also been working on an experimental, proof-of-concept implementation of ResourceSync (http://www.openarchives.org/rs/0.9/)
[20:47] <RichardJones> This code is absolutely not fit for inclusion into 4.0
[20:47] <RichardJones> but I would like a nice way of circulating it in a way that other DSpace users could easily include it to evaluate or ultimately contribute to
[20:47] <hpottinger> (my notes on submodules and pulling out theme files: http://lso.umsystem.edu/~pottingerhj/article/23/how-to-pull-theme-files-out-of-a-dspace-git-repository-into-their-own-git-repository)
[20:47] <kompewter> [ article: hardy@lso: how to pull theme files out of a DSpace git repository into their own git repository ] - http://lso.umsystem.edu/~pottingerhj/article/23/how-to-pull-theme-files-out-of-a-dspace-git-repository-into-their-own-git-repository)
[20:48] <RichardJones> hpottinger: I did play with the git filter-branch for a while, but I didn't get quite the result I was looking for
[20:48] <RichardJones> that allowed me to filter just a directory, but I also need to extract some config files in a different directory from the main code (which resides in dspace-swordv2)
[20:49] <RichardJones> basically, I'm a really low-skill git user :)
[20:49] <tdonohue> So, it sounds like (in a way), RichardJones, you are actually asking for a "plugin model" for DSpace? (I.e. a way to build these third party modules and make them easy to install in a DSpace). At least that seems to be the idea for ResourceSync.
[20:49] <RichardJones> tdonohue: yes, I think so, but also perhaps more
[20:50] <tdonohue> With the SWORDv2 stuff...the ideal would have been to "fork" our main GitHub repo, and build from that. But, until this morning, our "dspace-1_8_x" branch in GitHub was broken (as it still pointed at SVN), so forking it would not have helped
[20:50] <PeterDietz> So, either some git-magic to allow for a (sub)project to be trackable in multiple repositories. Or to just make it into a standalone plugin/module
[20:50] <RichardJones> so, for example, if I wanted to continue development of the DSpaceSWORDv2 module, and periodically contrib changes, is there an easier way than the current set up. (e.g. use of git submodules)
[20:50] <hpottinger> I like the idea of using a git submodule, to keep the plugin's history separate from the core repository history
[20:51] <PeterDietz> git submodule / git subtree merge sound like good options.
[20:51] <mhwood> Something like ResourceSync can be a free-standing project that depends on DSpace artifacts and just drops in alongside DSpace.
[20:51] <RichardJones> PeterDietz: possibly; I don't want to suggest a solution myself, as I don't have the knowledge
[20:52] <PeterDietz> We've had this issue of dspace code, that isn't in the repository with the dspace-services code. I think that if something is IN DSpace, we want to see it in the DSpace source tree
[20:52] <hpottinger> RichardJones: maybe outline what it is you'd like to happen, and then we see if we can figure out a way to make it happen, using existing tools?
[20:52] <RichardJones> mhwood: yes, almost - the main issue is that you can't just drop in the webapp - you need to add the dependencies to the main DSpace pom, as it also has a CLI component
[20:52] <mhwood> I'm unsure why one couldn't just fork DSpace/dspace, create a SWORDv2-development branch, and from time to time request pulls back to DSpace/dspace.
[20:53] <RichardJones> mhwood That was my plan originally, but it seems to have become tricky to feed that code back
[20:53] <tdonohue> what part is "tricky", do you recall?
[20:54] <RichardJones> hpottinger: well, what I want to do is what is best for DSpace; I certainly can see the desire to have the code that is in DSpace IN DSpace
[20:54] <mhwood> The ResourceSync CLI component can be packed in a distinct JAR, and the install procedure just places it in [DSpace]/lib. It becomes part of the classpath automagically. The tricky bit is getting the launcher to recognize it. I don't think we have that kind of modularity yet.
[20:55] <RichardJones> tdonohue: well, it's against a version of DSpace that's a few revisions old, and merging it forward and also extracting all the stuff that isn't to be contributed to DSpace seems difficult/impossible without losing revision history
[20:55] <RichardJones> mhwood: that doesn't address the issue of the additional dependencies of the CLI module
[20:56] <mhwood> Install those JARs too?
[20:56] <RichardJones> otherwise, that is basically how the code works already, I have a -classes.jar that can be deployed
[20:56] <tdonohue> So, I wonder if there are two parallel (seemingly similar, but possibly not) issues here: (1) How to contribute changes to *existing* DSpace modules (ones already in the codebase) and (2) How to maintain a third-party module which just "plugs into" DSpace (but isn't out-of-the-box)
[20:56] <RichardJones> yes
[20:57] <tdonohue> (1) is something that could be helped by Git-fu. But, (2) is something that really cannot...it's more an issue around how difficult it may be to install a "plugin" to DSpace
[20:58] <RichardJones> tdonohue: for the record, it is waaay easier these days to add new webapps to DSpace. It's really incorporating any schema changes, configuration or CLI-related stuff that requires manual intervention
[20:58] <RichardJones> I suppose there's also a sort of (3) how to alert DSpace users that such 3rd party modules exist
[20:59] <hpottinger> The App Store! :-)
[20:59] <RichardJones> :D
[20:59] <tdonohue> yep, I agree. I just know that #2 & #3 also affects things like "dspace-replicate" plugin cause it adds new configs/CL stuff (https://github.com/DSpace/dspace-replicate)
[20:59] <tdonohue> So, I can understand the concern here..it's one I have as well. I think the unfortunate reality is "we don't have an answer, yet". But we need to figure out a better way
[21:00] <RichardJones> EPrints has this "Bazaar", and while that's perhaps not quite right for DSpace, something along those lines would be great
[21:00] <mhwood> Configuration is more modular these days too, if we exercise some discipline over the configuration namespace (which hasn't been done so much in the past.)-:
[21:00] <PeterDietz> I'm wondering if our plugin/module structure is a bit creaky.. Meaning can Richard's module bring its own schema-updates, CLI additions, and config additions.. Or to work, does it need to inject something into dspace/config dspace/lib, ...
[21:00] <tdonohue> I think we *do* have some answers around #1 (contributing changes back)...mostly around Git. But, the third-party plugin model is still a bit lacking
[21:00] <RichardJones> I'd be very happy to work with someone to help me figure out the git-fu required to contrib back what I have so far
[21:01] <RichardJones> (with revision hsitory)
[21:01] <mhwood> I think the CLI stuff can be modularized with a little work on the launcher to read more than one configuration file. Config can probably be managed without a lot of work. Schema is the killer.
[21:01] <mhwood> Schema will want tools, and again namespace discipline.
[21:01] <RichardJones> I've tried to keep config separate where possible, but some changes are additions of new plugins which require plugin configurations which are in dspace.cfg to be modified
[21:02] <mhwood> Ugh, yes, the plugin manager configuration scheme needs thorough rework.
[21:02] <hpottinger> Schema is applied by a tool, the tool could be revised to look in new locations
[21:02] <RichardJones> fortunately, in these particular modules, I don't have schema changes - but it is something I have encountered before
[21:02] <tdonohue> For the example of "dspace-replicate". it just adds new configs (needing to be placed manually in dspace/config/modules) and pulls in new JARs. The step of having to manually add configs to your DSpace would be nice to cleanup.
[21:03] <RichardJones> there's also things like adding/removing xmlui aspects
[21:03] <tdonohue> So, I agree, schema changes may not necessarily be the most prevalent use case here... more likely to need to add new configs/JARs
[21:03] <mhwood> If an add-on is laid out the same way as DSpace then it can just be copied over [DSpace] so long as it doesn't collide with existing files.
[21:03] <mhwood> Ant could do that.
[21:05] <hpottinger> well, we're over-time, but I do have an announcement of sorts, the RT has conferred, and we have selected an RC (tentative, if we get more RT members, we can re-vote): mhwood is the 4.0 RC, for now, anyway, all hail mhwood, and extend him your thanks.
[21:05] <tdonohue> mhwood: I have often wondered if we just need a simple "addon package" (zip file) which Ant can unzip & install for you. We'd just need to define what that Zip structure looks like and build the ant tools to manage install/uninstall/upgrade
[21:06] <hpottinger> tdonohue: I think Richard Rodger's MDS does that
[21:06] <mhwood> The plugin manager needs work. Maybe Spring-ify it and drop plugin config. stuff (which is rather structured, bad for .properties format) into Yet Another config/spring/blah directory.
[21:06] <tdonohue> yay for mhwood as 4.0 Release Team leader!
[21:07] <tdonohue> hpottinger: yea, I think RichardR's MDS work does have something like that...although the painful part is figuring out how to "upgrade" an add-on.
[21:07] <RichardJones> mhwood: great :) just let me know what I can do to help the swordv2 contrib along in the appropriate way
[21:07] <mhwood> Will do.
[21:08] <tdonohue> I think we just need to find someone with a bit of Git-fu to help out, RichardJones. I'd be willing, but my time is lacking right now... maybe if I can find some hours
[21:08] <RichardJones> would be much appreciated!
[21:08] <hpottinger> I propose we sort this out over a pint of beer on PEI
[21:08] <RichardJones> +1
[21:08] <tdonohue> +1
[21:09] <hpottinger> It *will* be a hackathon day anyway
[21:09] <mhwood> We need a list of "integration points" for add-ons, so we know what to work on and can see if there are some which could be consolidated somehow.
[21:09] <tdonohue> I think our open question here is "how do we ease the installation of third-party 'add-ons'". This is a topic we need to touch back on
[21:10] <RichardJones> mhwood: I've done a /load/ of add-on stuff for DSpace, so can help brainstorm that
[21:10] <hpottinger> actually, we may sort it out in the pub, but I think the conversation should start at the Dev mtg
[21:10] <mhwood> Good, thank you.
[21:11] <mhwood> Agenda item for Dev meeting: what new modularity do we need to ease the creation/maintenance of add-ons?
[21:12] <tdonohue> some add-on "integration points" already mentioned today: configs, dependencies (JARs), XMLUI Aspects, XMLUI themes?. Not as prevalent (but possible): DB schema
[21:12] <tdonohue> mhwood: good topic, will add it
[21:12] <RichardJones> metadata and format registries
[21:13] <hpottinger> shellfish reminder: if any of you have upgraded to 3.1 and want to crow about it, e-mail me
[21:13] <tdonohue> As we are "over time", obviously no more official topics for today (and I may be going into "lurking" shortly). But, feel free to continue discussion as long as you wish to.
[21:14] <RichardJones> it's quite late here, so I may slink off
[21:14] <hpottinger> brb, need tea
[21:14] <RichardJones> looking forward to the dev mtg at or13 though
[21:14] <tdonohue> thanks for staying up late for us, RichardJones. See you at or13!
[21:14] <mhwood> Metadata needs thought about modularity. Fortunately there are already people thinking about disentangling all the stuff that got/gets piled into our "DC" schema.
[21:14] <RichardJones> will be good to catch up with all
[21:16] <RichardJones> ok, thanks for listening to my ramblings folks, see you soon!
[21:16] <mhwood> See you there.
[21:16] * RichardJones (~richard@188-222-5-105.zone13.bethere.co.uk) has left #duraspace
[21:18] <mhwood> I have to go too. 'bye all.
[21:18] <kstamatis_> bye everyone
[21:18] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:19] * l_a_p (~chatzilla@31.189.204.32) Quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803])
[21:19] * kstamatis_ (5b8c1947@gateway/web/freenode/ip.91.140.25.71) has left #duraspace
[21:21] <hpottinger> I'm back, but, alas, everyone has left
[22:09] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:09] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[22:24] -tomaw- [Global Notice] Hi all, we just experienced a little unexpected issue with the webchat resulting in all its users being momentarily kicked off the service. It's back working correctly now. Sorry for the inconvenience!
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.