Timestamps are in GMT/BST.
[2:51] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) has joined #duraspace
[3:20] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[3:21] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[3:25] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Ping timeout: 250 seconds)
[5:54] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[6:33] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[6:34] -holmes.freenode.net- *** Looking up your hostname...
[6:34] -holmes.freenode.net- *** Checking Ident
[6:34] -holmes.freenode.net- *** Found your hostname
[6:34] -holmes.freenode.net- *** No Ident response
[6:34] [frigg VERSION]
[6:34] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:34] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:34] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:38] -jordan.freenode.net- *** Looking up your hostname...
[6:38] -jordan.freenode.net- *** Checking Ident
[6:38] -jordan.freenode.net- *** Found your hostname
[6:38] -jordan.freenode.net- *** No Ident response
[6:38] [frigg VERSION]
[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:27] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) Quit (Quit: alxp)
[8:21] * scottatm (~scottatm@voyager117.evans.tamu.edu) Quit (Ping timeout: 252 seconds)
[12:01] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) has joined #duraspace
[12:29] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:52] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) Quit (Quit: alxp)
[13:22] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[13:37] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) has joined #duraspace
[14:00] * scottatm (~scottatm@voyager117.evans.tamu.edu) has joined #duraspace
[14:45] * Mayank (~MnzNotebu@122.161.218.56) has joined #duraspace
[15:39] * robint (81d7a972@gateway/web/freenode/ip.129.215.169.114) has joined #duraspace
[15:44] * robint (81d7a972@gateway/web/freenode/ip.129.215.169.114) Quit (Quit: Page closed)
[16:59] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) has joined #duraspace
[17:32] * snail (~stuart@130.195.179.88) Quit (Ping timeout: 276 seconds)
[17:45] * snail (~stuart@130.195.179.88) has joined #duraspace
[18:31] * Mayank (~MnzNotebu@122.161.218.56) Quit (Ping timeout: 260 seconds)
[19:05] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:05] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[19:05] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[19:09] <tdonohue> Reminder to all -- our DSpace Developers meeting is in about 1 hour from now, still at 20:00UTC. For those in the USA/Canada, as it's now Daylight Savings, this means the meeting is now an hour later than it used to be.
[19:14] * Mayank (7aa1da38@gateway/web/freenode/ip.122.161.218.56) has joined #duraspace
[19:27] * Mayank (7aa1da38@gateway/web/freenode/ip.122.161.218.56) Quit (Ping timeout: 252 seconds)
[19:30] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:31] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) has joined #duraspace
[19:45] * bojans (~Bojmen@91-118-63-19.dynamic.adsl-line.inode.at) has joined #duraspace
[19:46] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:54] <tdonohue> Hi all, reminder, at top of the hour is our DSpace Developers Meeting. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-16
[19:55] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:56] * cccharles (~user@131.104.62.55) has joined #duraspace
[19:59] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) has joined #duraspace
[20:00] <tdonohue> Hi All. Today is a DSpace Special Topic meeting on the "RoadMap to 2.0". As I had sent out previously, I've mocked up a proposed RoadMap that I feel would be beneficial to DSpace over the next few releases
[20:00] <tdonohue> https://wiki.duraspace.org/display/DSPACE/Proposed+RoadMap+to+2.0
[20:00] <kompewter> [ Proposed RoadMap to 2.0 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org
[20:00] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <tdonohue> The point of this meeting is to begin to brainstorm out a RoadMap to 2.0, via a set of releases....
[20:02] <tdonohue> The proposal that I made is simply *my* ideas for a potential RoadMap, so I'd like to also hear your responses / disagreements with this approach.
[20:02] <richardrodgers> One fundamental question I have is around continuity
[20:02] <tdonohue> I also fully realize that this is a *HUGE* topic...so, I expect it will be an ongoing discussion, and I also expect this discussion will also continue at our face-to-face at OR11
[20:03] <tdonohue> go ahead, richardrodgers...if you'd like to start things off
[20:03] <richardrodgers> That is, is the road to 2.0 via the 1.x code?
[20:03] <mdiggory> Yes, continuity is of the utmost import
[20:03] <tdonohue> Yes..it's a way of stepping from where we are now (1.7.0) to a *real* 2.0
[20:03] <mhwood> That's what we've been doing so far.
[20:04] <richardrodgers> I know, but I'm not convinced it will get us there in the most efficient manner
[20:04] <mdiggory> Yes we are still on track with what I've suggested as a road forward at DSUG in Sweden and at OR10
[20:05] <mhwood> Most efficient...?
[20:05] <tdonohue> richardrodgers: well, that's what this discussion is all about. I wanted to just kick things off with a basic proposal, and then brainstorm out whether this is the "best" route, or if better ones may exist
[20:05] <mdiggory> I believe the community has need for continuity
[20:05] <richardrodgers> mhwood: what I mean is this:
[20:06] <grahamtriggs_> tdonohue: promise not to take my comments personally!! I'm liable to be quite harsh, but it's not meant to be taken that way.
[20:06] <richardrodgers> If we are layering in frameworks/ etc that need to retain compatibility with our code, we are adding complexity
[20:06] <tdonohue> I promise not to take anything personally. This RoadMap is merely *one idea*, and I'm perfectly fine if we take today to "rip it apart" and start over from scratch
[20:06] <richardrodgers> It may be simpler/easier to jump to what we want
[20:07] <mdiggory> me/ preparing for the grahamtriggs onslaught
[20:07] <richardrodgers> I don't know, but I think it merits consideration.
[20:07] <tdonohue> richardrodgers: so, are you proposing parallel development paths? And then a migration path between them?
[20:07] <richardrodgers> Let me give you some examples in current code:
[20:08] <mdiggory> richardrodgers: From experience, making any jump to "what we want" is both an enormous task and and one with a high risk of attrition
[20:09] <grahamtriggs_> First thing I'll say, is that we really need to get away from saying anything "2.0". This has been an dead albatross for us, and we've talked about re-numbering that makes "2.0" somewhat moot. Yes, we need to think about our roadmap over the next few releases, but the sooner we start breaking down ingrained notions, the better.
[20:09] <mdiggory> while awaiting richardrodgers examples, I will add that both the DSpace 2.0 work and our experience with trying to integrate have led us to working in more manageable "chunks"
[20:09] <richardrodgers> mdiggory: this is true, but we should also see the costs on the other side, they are not insignificant
[20:10] * JosephRhoads (a00a0f16@gateway/web/freenode/ip.160.10.15.22) has joined #duraspace
[20:10] <richardrodgers> one example, we put in a bunch of Spring stuff, which when we really need it, will likely have to be rewritten to (e.g. Spring 3 idioms)
[20:10] <tdonohue> to grahamtriggs_ first point: I probably shouldn't have called this "2.0" :) This RoadMap has *nothing* to do with past concepts of 2.0. So, you could instead think of this as a "Proposed RoadMap for 2011-2013" (which happens to have a release that I chose to name "2.0")
[20:11] <richardrodgers> there was nothing wrong with the work, it just wasn't put to extensive use, and things move on. We carry this as technical debt
[20:12] <kshepherd> hi all
[20:13] <mdiggory> We do see incredible value in the dspace-services work and the adoption of Spring, and migrating to new spring 3.0 idioms is not a concern for us.
[20:13] <richardrodgers> I guess I'm just asking if we should consider this:
[20:13] <mdiggory> We see the adoption of Spring as a healthy force for improving the architecture of DSpace
[20:13] <richardrodgers> if the goal is a DSpace w/Fedora inside, then let's look at what that requires.
[20:14] <mdiggory> cleaning it up and separating the functional areas
[20:14] <tdonohue> richardrodgers: the reason I went with this sort of "staged" approach was to limit the need for all of us to "work simultaneously in two codebases". So, I was hoping to simplify that, by making *small steps* over a series of releases, that can gradually bring our API to a "better" place.
[20:14] * Mayank (~MnzNotebu@122.161.218.56) has joined #duraspace
[20:14] <mdiggory> \me agrees with tdonohue on this point
[20:14] * cccharles (~user@131.104.62.55) Quit (Remote host closed the connection)
[20:14] <mhwood> DSpace/Fedora is *a* goal.
[20:14] <grahamtriggs_> Right, now to get controversial :) I don't really see the proposal as a roadmap - it's a collection of ideas of things that are implemented / half-implemented / desired, that might be able to be able to go into versions at those times. There are more trade-offs, and built-up legacy revolving around developing those features than is acknowledged. And I'll get back to my pet peeve as a concrete example...
[20:14] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:15] * mdiggory agrees with mhwood on this point
[20:15] <tdonohue> richardrodgers: I should have mentioned that more explicitly, but *simultaneous* to this entire RoadMap there *will* be a smaller group looking at what DSpace w/Fedora inside entails as a goal, and some of that may eventually affect this RoadMap over time
[20:15] * tdonohue agrees with mhwood as well
[20:15] <richardrodgers> tdonohue: right, but the more we succeed on the modularity front, the more that that issues diminishes
[20:15] <mdiggory> richardrodgers: I would suggest thats why its more of a priority on the 1.8 release
[20:15] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) has joined #duraspace
[20:16] * mdiggory agrees with grahamtriggs as well ;-)
[20:16] <richardrodgers> mdiggory: I agree that modularity could give us a big win in that time-frame, I'm not talking about that
[20:17] <mdiggory> richardrodgers: you mean the issues of parallel tracks of development?
[20:18] <richardrodgers> mdiggory: yes, to the degree we can disaggregate the system, then parallel becomes the rule, not an extra toll
[20:18] <mdiggory> ok...
[20:18] <mdiggory> Quote: richardrodgers: if the goal is a DSpace w/Fedora inside, then let's look at what that requires.
[20:19] <mdiggory> We have already been working on parallel tracks in this area for a few years now
[20:19] <tdonohue> grahamtriggs_ : would like to hear more out of that...what do you see as necessary to make this more of a "roadmap" . I'll also admit, that parts of this likely are not truly a RoadMap, but are more meant to get us to *discuss* and decide upon a RoadMap as a group :)
[20:20] <mdiggory> however, I argue that while parallel tracks appear to converge in the distance, they do not unless connections are built
[20:21] <mdiggory> and incremental switches along the track assure that congestion will be alleviated if there are conflicts with traveling to our destination
[20:21] <richardrodgers> true mdiggory , but I'm saying is that convergence is not in building just infrastructure that can get you there, but a functional set of requirements...
[20:21] <mhwood> richardrodgers: so what do you want to do?
[20:22] <grahamtriggs_> Whilst I absolutely acknowledge that there needs to be a REST API, if a Fedora based system is the endpoint (and I have big reservations about the suitability of Fedora for the community at large - somewhat separate issue), having Fedora gives us a lot of that anyway. Rushing to implement/support a REST API that is not the same as Fedora (so that we can't just ditch parts of it and simply expose the Fedora API),
[20:22] <grahamtriggs_> will be a significant resource drain. I stand by saying that the thought between these needs to be joined up - either the REST API (where possible) matches the API of Fedora, or we wait for Fedora, or we just have an API and forget about Fedora.
[20:22] <richardrodgers> mhwood: I'd really like to understand what we want to build first
[20:23] <mhwood> I suspect that we all understand what we want to build, but our understandings are all different.
[20:24] <richardrodgers> mhwood: I'm worried that a lot of good stuff we did in the past, (which was done without reference to, or guided by 'Fedora inside') may or may not fit the best
[20:25] <richardrodgers> So I just want to know what the community sentiment is about our priorities.....
[20:25] <mdiggory> richardrodgers: I agree as well, and have been very quick to point out to the initiative that there is prior art to consider
[20:26] <tdonohue> grahamtriggs_ : Not sure I get your point. I see a DSpace REST API as being inherently different from a Fedora REST API, as they are two entirely different object models/APIs, and wrap different object/content workflows (even if DSpace sits on Fedora)
[20:27] <richardrodgers> mdiggory: right, there is prior art on both sides, and I'm not sure we have tried to analyse it yet
[20:27] <tdonohue> richardrodgers: So, some of the *priorities* that I proposed are at the top, in the "Overarching Goals": https://wiki.duraspace.org/display/DSPACE/Proposed+RoadMap+to+2.0
[20:27] <kompewter> [ Proposed RoadMap to 2.0 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org
[20:27] <mhwood> First, do we even have a consensus on what things we are prioritizing?
[20:28] <tdonohue> I'd be fine with taking a step back and discussing priorities
[20:29] <mhwood> What does DSpace look like when we are done?
[20:29] <tdonohue> I think that'd be a worthwhile exercise. As mentioned, my general priorites (they are a bit high-level) are in the Overarching Goals, I defined in the proposal
[20:30] <grahamtriggs_> tdonohue: which in itself is a problem. If we expose a DSpace REST API as being tied to what is currently the DSpace model, then we introduce another big headache in maintaining/extending/replacing that API and evolving the platform, and if we stick to further baking in our object model, then we gain *nothing* by incorporating Fedora underneath.
[20:30] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) Quit (Quit: Page closed)
[20:31] <mdiggory> grahamtriggs, Baby steps... IMO, we cannot make the jump to a flexible data model without first having an existing data model.
[20:32] <mdiggory> tdonohue: think these needs labels or numbering
[20:32] <mdiggory> Begin to Restructure Trunk Projects -
[20:32] <mdiggory> Begin Refactoring the DSpace Domain Model -
[20:33] <mdiggory> consider the second a higher priority than the first
[20:33] <tdonohue> To answer mhwoods question of "what does DSpace look like", I'd like to see DSpace become a more *central*, interoperable system which is able to more easily share its content via improved integration points/APIs/etc.
[20:33] <mdiggory> Yes, API / Integration points need to be "Contracts"
[20:34] <tdonohue> At the same time, I'd also like to see DSpace become *easier to install & configure*, so that it's easier for people to get up and running & stay up-to-date.
[20:35] <tdonohue> Again, I've listed these priorities at the top of the RoadMap proposal. But, I'd be interested to hear what *you all think*. Are these common priorities? Would you answer the question of "what does DSpace look like" differently?
[20:36] <mhwood> I should have said: what does DSpace look like *inside*?
[20:36] <tdonohue> ok, so, you are talking *technical architecture priorities*, rather than overarching priorities...
[20:37] <mdiggory> Yes, I don't think we disagree with the overarching goals (or at least I don't)
[20:37] <tdonohue> *inside*, as a basic answer, I'd say I feel it would be beneficial to minimally have "Fedora Inside" as an *option* (it may or may not be the only option, that is yet to be decided)
[20:37] <mhwood> "Fedora Inside" probably needs to be put on the map explicitly.
[20:38] <mdiggory> I think we all get "heated" when ti comes to how those goals will be reached and what the solutions will look like
[20:38] <tdonohue> sorry, I thought it was explicit -- it's in 2.0 on the map, and it's also listed under priorities?
[20:38] <mhwood> Oops, yes, there it is.
[20:39] <mhwood> Yes, we get heated and then back off to cool down. We need, at some point, to fight to a decision.
[20:39] <PeterDietz> A goal that I want is to be able to have a third party, non-Java user interface (i.e. php-UI). it can talk either through DSpace REST API, or perhaps discovery+solr search index.
[20:39] <tdonohue> but, obviously, I'll admit, my saying "Fedora Inside" doesn't mean a lot yet. We really haven't figured out *what that means* (but we do have a team who is starting to look into that, of both DSpace & Fedora folks -- if you are interested in helping, please get in touch)
[20:40] <kshepherd> if we haven't figure dout what it means...
[20:40] <kshepherd> how do we know we want it? ;)
[20:40] <richardrodgers> tdonohue: that's my point - we need to drill down on it because it has strong architectural requirements
[20:41] <richardrodgers> or could have
[20:41] <mdiggory> I think for the group, the highest priority is achieving some consensus on if we should be standardizing on modularity approaches
[20:41] <tdonohue> richardrodgers -- yes, it will *inform* this roadmap going forward. But, that's also explicitly *why* I don't go into much detail in the "DSpace 2.0" section of the roadmap
[20:41] <richardrodgers> do you mean the proposal to explode dspace-api, etc, mdiggory ?
[20:42] <mhwood> One thing I just realized I *don't* see on the map is the simplification of containment that was done in the 2.0 prototype. Are we still doing that, and if so, how does it play with all the other stuff people want to do?
[20:42] <mdiggory> richardrodgers: "explode" is a dangerous way to word it
[20:43] <richardrodgers> sorry ;)
[20:43] <tdonohue> PeterDietz -- That is also a goal of mine. I'd personally like to see other third party interfaces pop up. See last sub-bullet of #3 under DSpace 1.9.0: "Encourage community to developer/share/support their own third-party UIs"
[20:44] <mdiggory> for instance "Begin Refactoring the DSpace Domain Model -" is not breaking apart dspace-api, its actually "formalizing" an API contract that is present within it
[20:44] <richardrodgers> no, I thought you meant the trunk projects stuff....
[20:44] <mdiggory> and once "formalized" theres now room to discuss how to change it
[20:44] <tdonohue> mhwood. You are right, that was a mistake. Should be in there somewhere, and will be necessary as we move towards "Fedora Inside". Though that simplication of containment is likely either a 1.9.0 or a 2.0 (as part of final refactoring for Fedora Inside)
[20:44] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[20:45] <mdiggory> richardrodgers: I think that considering more functional "modules" is still relevant
[20:45] * tdonohue notes that i now numbered the bullets under each version in RoadMap. Refresh your page to see them. The numbering is just for ease of reference, and not to represent something being of higher/lower priority
[20:45] <mdiggory> and dividing up dspace-api certainly would lead us to be able to approach more sulutions / modules or "bricks"
[20:46] <mhwood> mdiggory: what I'm hearing is that we all have been working over stuff that was designed long ago, and it's time for another design cycle to clean up the current state of it and ensure that it fits where we want to go.
[20:46] <mdiggory> mhwood: yes, that is certainly an incremental approach
[20:48] <tdonohue> So, are there other priorities any of you would like to express? Do you disagree or agree with priorities as stated in the RoadMap proposal, or is something glaringly missing / wrong?
[20:49] <mdiggory> and I could word in many different ways.... I don't want to see this on an OR11 presentation slide ;-) Theres a great deal that was learned in the DSpace 2.0 initiative about the importance not chopping off the hand that feeds you.
[20:50] <tdonohue> kshepherd -- sorry I missed your comment about "how do we know we want Fedora Inside". I'd say, right now we *think* it's a good idea, but we are still investigating it. It's just a goal at this point.
[20:50] <mdiggory> sorry, I guess that was a botched metaphor, should have been bite.
[20:51] <tdonohue> kshepherd -- also, the reasons why DuraSpace feels that the "Fedora Inside" idea is a worthwhile goal are detailed in the FAQ at
[20:51] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace-Fedora+Integration+FAQ#DSpace-FedoraIntegrationFAQ-Whataretheperceivedbenefits%3FWhydothisintegration%3F
[20:51] <kompewter> [ DSpace-Fedora Integration FAQ - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org
[20:51] <mdiggory> tdonohue: its ok so far, though ordering and content of 1.8.0 and 1.9.0 may be subject to change
[20:52] * Mayank (~MnzNotebu@122.161.218.56) Quit (Ping timeout: 240 seconds)
[20:52] <tdonohue> That being said, I would be interested to hear from any of you around how you feel about "Fedora Inside" idea (like/dislike). You are also welcome to contact me outside of this meeting, if this is "too public"
[20:53] <mdiggory> I do want to emphasize...
[20:53] <mdiggory> mdiggory: I think for the group, the highest priority is achieving some consensus on if we should be standardizing on modularity approaches
[20:53] <kshepherd> i don't have a strong opinion, i just assumed others already did (have strong opinions)
[20:53] <mhwood> Is there an argument for *not* standardizing on modularity approaches?
[20:54] <richardrodgers> I'm not entirely clear on what is meant in this context....
[20:54] <mdiggory> ok, it has to do with the technical track of the roadmap
[20:55] <mdiggory> IMO, the first two items and Replace DSpace ConfigurationManager and PluginManager) present a very clear attack on the current PluginManager and ConfigurationManager approaches to modularity.
[20:56] <mdiggory> and are directing a solution that utilizes dspace-services to attain modularity / plugability via spring instead
[20:56] <richardrodgers> Ok - but first they still need work, no?
[20:56] <mdiggory> My position is that this is standardizing an approach to modularity
[20:57] <mhwood> So you mean picking a particular approach and deprecating...removing others.
[20:57] <mdiggory> mhwood: that is correct
[20:57] <mdiggory> richardrodgers: yes, there is work still, it is incremental
[20:58] <mdiggory> though, "Refactoring the DSpace Domain Model" is almost completed and there are a series of changes to the dspace-api that we want to give the community an opportunity to review before a commit happens.
[20:58] <richardrodgers> And I thought grahamtriggs had some further work on services?
[20:58] <mdiggory> grahamtriggs always has further work on services ;-)
[20:59] <kshepherd> the stuff in Refactoring Domain Model makes sense
[20:59] <mdiggory> the mans a debugging machine
[20:59] <mhwood> So, rewording again, we need to decide as a group whether ConfigurationService etc. are our direction, and all commit to something.
[20:59] <mdiggory> mhwood: well put
[21:00] <richardrodgers> the Domain Model stuff I think is most in need of explicitly lining up to Fedora Inside reqs, which I have yet to see...
[21:01] <mdiggory> Do you want a mapping?
[21:01] <richardrodgers> yes, for a start
[21:01] <mdiggory> or a description of how it relates to a persistence approach
[21:01] <mdiggory> well, coming back to modularity...
[21:02] <mdiggory> pluggable DAO = opportunities for mutliple mappings / approaches
[21:03] <mdiggory> pluggable DAO + Storage Services = opportunities for multiple mappings + storage solutions
[21:03] <tdonohue> I'm noting we are already over time here...should we take time to dig deeper & vote on modularity suggestions either (a) in this meeting sometime in next few weeks or (b) via email ?
[21:03] <richardrodgers> yes, but that is a rather generic, abstract view. I want to examine something closer to an implementation architecture
[21:04] <mdiggory> I think going back to what the goal of the original DAP prototype was... it was to get the implementation out of the model, so that there could be alternatives.
[21:04] <mdiggory> DAP =DAO
[21:04] <richardrodgers> I do have to go ATM - but this is an important discussion.....
[21:04] <JosephRhoads> I agree. And also have to go.
[21:05] <richardrodgers> bye all, thanks
[21:05] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:05] <mdiggory> well, the point is well taken, I think that its important to note that the Domain Model and DAO have other important roles outside of Fedora Inside
[21:06] <mdiggory> Ok, thanks tdonohue for what was a very successful special topic meeting
[21:07] <tdonohue> So, obviously, I think there's a lot that still needs deeper discussion here...
[21:07] <tdonohue> I think we should schedule a meeting to talk about modularity suggestions over the coming weeks..
[21:08] <mdiggory> I agree, I worry about creating dependencies on moving forward now that rely on understanding exactly what will happen in 2.0
[21:08] <tdonohue> I'd also encourage *everyone* to add your ideas/concerns/suggestions to that RoadMap Proposal, on dspace-devel, on dspace-commit, or send them to me. I really want to make sure we are all "heading in the same direction" and have a common understanding/agreement on that direction
[21:09] <tdonohue> I don't think we've yet come to an *exact* agreement, but I think we had good discussion and found some commonalities
[21:10] <tdonohue> So, with that...I'll close off the meeting. Feel free to let me know what you think. Also, start thinking of topics we may want to tackle in person at OR11 (where we will have time to dig in together on bigger topics)
[21:10] <kshepherd> any updates/thoughts/ideas on GSoC, and/or the stuff i sent to dspace-commit last week?
[21:10] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) has joined #duraspace
[21:11] <tdonohue> GSoC updates = still put in your Project ideas on the wiki or volunteer to mentor a project. We don't know yet if we are "accepted" (but we should find out on Friday)
[21:11] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) Quit (Quit: Leaving.)
[21:11] <mdiggory> tdonohue: it would be good to get a roadmap for GSoC application published and maybe make reminders to the dev list
[21:11] <tdonohue> GSoC Project ideas go here: https://wiki.duraspace.org/display/DSPACE/Google+Summer+of+Code+Ideas
[21:11] <kompewter> [ Google Summer of Code Ideas - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org
[21:12] <tdonohue> mdiggory -- first, we gotta get accepted. But, yes, I agree!
[21:12] <mdiggory> that risk is quite low
[21:14] <tdonohue> still, mdiggory, was planning to send out reminders to dspace-devel once we are accepted on Fri (fingers crossed)...
[21:15] <tdonohue> As for 1.7.1 release -- It sounds like there were concerns about pushing it up? Should we leave it where it is scheduled (Friday, March 25)? I feel like the discussion has *stopped* or never got started on dspace-commit (and I'm not sure why that is)
[21:15] <mhwood> Sorry, must go. Good discussion!
[21:15] <kshepherd> i'm not sure either
[21:15] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:16] <tdonohue> at this point, March 25 is not too far off, so I'm OK with waiting as needed. I feel this really is a call for 1.7.1 Release Coordinator to make. I don't want to get in the habit of making these decisions on behalf of the RC.
[21:16] <kshepherd> is PeterDietz around?
[21:16] <PeterDietz> hi
[21:17] <PeterDietz> do we have a solid fix for the dspace-commit issue?
[21:17] <kshepherd> PeterDietz: if you have any comments/questions/decisions on the issue i emailed dspace-commit about, feel free to reply there :)
[21:17] <kshepherd> (and just a note that this channel is logged)
[21:18] * tdonohue notes that I am unfortunately "on call" for Jury Duty all of next week (March 21-25). I'm hoping to not get chosen on a jury, but if I do, my ability to help with 1.7.1 release may be limited.
[21:20] <tdonohue> I'd suggest PeterDietz or kshepherd starting up this conversation again on dspace-commit...
[21:20] <kshepherd> ok
[21:21] <PeterDietz> from what I said in email, the dspace-commit and discovery+sword issue need to be in a 1.7.1
[21:22] * tdonohue is only going to be here "partially" for a while. If others need to head out, feel free (consider the main meeting to be closed). But, also feel free to stick around if you want to continue discussion..
[21:22] <kshepherd> PeterDietz: hrm, didn't see an email from you. can you resend?
[21:24] <PeterDietz> kshepherd: I had apparently sent through my gmail address, instead of my @osu.edu address, and the message was dropped
[21:25] <kshepherd> got your re-send
[21:26] <kshepherd> ta
[21:41] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) Quit (Quit: KevinVdV)
[21:44] * bojans (~Bojmen@91-118-63-19.dynamic.adsl-line.inode.at) Quit (Remote host closed the connection)
[21:45] * Mayank (~MnzNotebu@122.161.218.56) has joined #duraspace
[21:57] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) Quit (Quit: Page closed)
[22:05] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[22:09] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[22:29] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Ping timeout: 252 seconds)
[22:57] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) Quit (Quit: mdiggory)
[23:04] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs_)
[23:16] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has left #duraspace
[23:17] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) Quit (Remote host closed the connection)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.