Timestamps are in GMT/BST.
[0:06] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[0:27] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[1:40] * ksclarke (~kevin@184.39.30.147) Quit (Quit: Leaving.)
[1:57] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[2:03] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[2:04] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[2:33] * achelous (~tom@174-126-228-87.cpe.cableone.net) Quit (Ping timeout: 258 seconds)
[2:43] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[2:45] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Ping timeout: 240 seconds)
[2:45] * mdiggory_ is now known as mdiggory
[4:06] -hubbard.freenode.net- *** Looking up your hostname...
[4:06] -hubbard.freenode.net- *** Checking Ident
[4:06] -hubbard.freenode.net- *** No Ident response
[4:06] -hubbard.freenode.net- *** Found your hostname
[4:06] [frigg VERSION]
[4:06] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:18] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[4:19] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[5:25] * pvillega_ (~pvillega@62.77.170.185) has joined #duraspace
[5:29] * pvillega (~pvillega@62.77.170.185) Quit (Ping timeout: 260 seconds)
[7:00] * pvillega__ (~pvillega@86.47.50.67) has joined #duraspace
[7:03] * pvillega_ (~pvillega@62.77.170.185) Quit (Ping timeout: 264 seconds)
[7:07] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[8:22] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[8:37] * ksclarke (~kevin@184.39.30.147) has joined #duraspace
[8:37] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[8:37] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[9:04] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[9:13] * cbeer (~cbeer@146.115.109.226) has joined #duraspace
[9:34] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:43] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[10:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[11:14] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:15] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[11:16] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[11:18] * pvillega__ (~pvillega@86.47.50.67) Quit (Ping timeout: 245 seconds)
[11:33] * pvillega_ (~pvillega@62.77.170.185) has joined #duraspace
[11:33] * pvillega (~pvillega@62.77.170.185) Quit (Read error: Connection reset by peer)
[11:33] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[11:34] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[12:26] * achelous (~tom@216.160.210.151) has joined #duraspace
[12:44] * pvillega_ (~pvillega@62.77.170.185) Quit (Remote host closed the connection)
[12:47] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[13:22] * achelous (~tom@216.160.210.151) Quit (Remote host closed the connection)
[13:27] * achelous (~tom@216.160.210.151) has joined #duraspace
[14:46] * bradmc_ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:46] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[14:46] * bradmc_ is now known as bradmc
[15:13] * ksclarke (~kevin@184.39.30.147) Quit (Quit: Leaving.)
[15:14] * ksclarke (~kevin@184.39.30.147) has joined #duraspace
[15:27] * ksclarke (~kevin@184.39.30.147) Quit (Ping timeout: 265 seconds)
[15:32] * ksclarke (~kevin@184.39.28.234) has joined #duraspace
[15:40] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:41] * cccharles (~chris@131.104.62.47) has joined #duraspace
[15:48] * pvillega (~pvillega@89.100.155.181) has joined #duraspace
[15:52] * carynn (~cneiswen@c726.staff.lib.uci.edu) has joined #duraspace
[15:54] * kshepherd orders a large flat white with 2 extra shots
[15:57] * tdonohue has no idea what kshepherd just ordered, but guesses it involves caffeine :)
[15:58] <tdonohue> DSpace Dev meeting will start in a few minutes. Agenda up at: http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-06-09
[15:59] * PeterDietz learns that flat white is Kiwi speak for fancy coffee-beverage http://en.wikipedia.org/wiki/Flat_white
[15:59] * tdonohue mmmm...that does sound good
[16:01] <tdonohue> Ok all -- may as well get things started here. (If anyone has anything to tack onto the agenda, feel free to send it along.)
[16:01] <tdonohue> GSoC updates are first -- as announced, the Unit Testing Project meets right here in 1hr -- so, stick around if you have time
[16:01] <tdonohue> mdiggory, did you have other GSoC updates to add?
[16:04] <kshepherd> heh, i forgot USA doesn't do "flat whites". i got strange looks when i tried to get one in Atlanta ;) like a small strong latte, i think
[16:04] <tdonohue> Ok, mdiggory must not be around yet -- one thing I saw (from dspace-gsoc-student listserv) is that they are attempting to have other project meetings earlier on in the day (so that students in other timezones can attend)
[16:05] <tdonohue> FYI -- it looks like their latest proposal for GSoC Student meetings is at 12:00UTC. I'm sure mdiggory will announce more widely once it is finalized
[16:06] <tdonohue> Any other GSoC updates? If not, we can skip ahead to 1.6.2 updates...
[16:07] <tdonohue> kshepherd (or stuartlewis) -- any updates on 1.6.2 status? Should we set a "date" / make an official announcement?
[16:08] <kshepherd> tdonohue: I haven't recieved a patch for DS-584 yet, but it seems as though all we really need to do is "UNIXify" the start-handle-server script you uploaded
[16:08] <kshepherd> so if i haven't heard from stuart by later this afternoon i'll do that myself, hopefully should have a few free minutes today since i started early
[16:09] <tdonohue> yea -- my version got all mucked up by NetBeans on Windows -- you should just be able to run 'dos2unix' to fix it
[16:09] <kshepherd> i've also confirmed with Jeff this morning that he's good to commit the upgrade instructions to doco (DS-604) in the next few days
[16:09] <kshepherd> s/upgrade/fixes to upgrade/
[16:10] <tdonohue> excellent -- so, 1.6.2 will just fix DS-584 (the biggie) and DS-604...correct?
[16:10] <kshepherd> correct. so perhaps we can announce for next wednesday (16th) to be on the safe side?
[16:11] <tdonohue> so, is that proposing you "cut" the release on Weds (16th), and that it likely becomes available in Maven Repo by the 17th (since I know there is quite a delay there, as we saw with 1.6.1)
[16:12] <kshepherd> mm.. i was thinking i could hopefully cut by the monday
[16:12] <tdonohue> essentially, I'm suggesting we announce the release date as being ~24hrs *after* you actually 'cut' the release (if that makes sense)
[16:12] <kshepherd> so weds would allow propagation
[16:13] <tdonohue> ok -- that's also fine -- I was just wanting to make sure you had left in that "buffer" for the propagation
[16:13] <kshepherd> yeah, definitely makes sense.. the average list reader wants to know when they can download it, not when i am first releasing it ;)
[16:13] <tdonohue> yep, exactly :)
[16:13] <mhwood> Not to mention that the Americas are so far behind....
[16:14] <tdonohue> ok, so kshepherd, do you want to draft up a 1.6.2 announcement then? or do you want me to?
[16:14] <kshepherd> this is assuming that Jeff is able to get the documentation in time. is anyone here good enough with docbook to raise their hand to be a backup person, in case Jeff gets busy this week?
[16:15] <mhwood> How complex is it? I am relatively new to DocBook but I can try.
[16:15] <kshepherd> tdonohue: hmm, if you're able to that'd be great, otherwise i can try to find time this afternoon while i'm doing the patch up
[16:15] <kshepherd> mhwood: i don't think it's very complex, but i haven't really even touched it before ;)
[16:16] <tdonohue> kshepherd -- I'll likely not get to it today -- but, I can draft it up tomorrow if you don't get to it (so, if I don't see a draft from you by the time I wake up tomorrow, I'll do it) :)
[16:16] <kshepherd> http://wiki.docbook.org/topic/DocBookTutorials
[16:16] <mdiggory> Sorry, today is very busy... it looks as though, until more formally defined, there will be Pere's GSoC meeting after this one. We will announce more formal scheduling on the other students, I hope before he end of the week.
[16:16] <tdonohue> thanks mdiggory for the GSoC update...
[16:18] <tdonohue> ok -- so, is mhwood the backup for jeff then?
[16:18] <mhwood> I'll take a look at DS-604 but it sounds like I can fill in on the DocBook stuff.
[16:18] <tdonohue> thanks mhwood! If either you or kshepherd run into problems, just yell my way (or on dspace-devel)
[16:18] <kshepherd> cool thanks, i'll get in touch if need be
[16:19] <tdonohue> Sounds good then -- I'm assuming that's it for 1.6.2 updates?
[16:19] <kshepherd> yep
[16:19] <tdonohue> Ok -- on to discussion topics...
[16:20] <tdonohue> I sent this out to committers, but it's possible some non-committers may haven't had a chance to review.. at OR10, DuraSpace will be recommending integration of Fedora with DSpace. We've started up a FAQ: http://wiki.dspace.org/confluence/display/DSPACE/DSpace-Fedora+Integration+FAQ
[16:20] <tdonohue> Essentially, we (DuraSpace) is looking for feedback from you (committers/developers/interested persons) around this idea, and the FAQ itself....
[16:21] <tdonohue> so, if anyone has any thoughts to share now (positive/critical/unsure), please feel free.... (If you haven't had a chance to review this, please, by all means email me offline)
[16:22] <tdonohue> a more formalized announcement is forthcoming -- we just wanted some initial feedback first
[16:22] <mdiggory> tdonohue: Ive been hunting for time to respond further, it is good that Duraspace recognizes this
[16:24] * robint (~52292565@gateway/web/freenode/ip.82.41.37.101) has joined #duraspace
[16:24] <tdonohue> thanks mdiggory -- send on a response when you get a chance
[16:24] <mdiggory> This is actually something that has been evolving for sometime within the community and I think that advertising the organizations position on it may lead to greater support, hopefully funding.
[16:24] <tdonohue> anyone else have thoughts on this DSpace-Fedora integration idea (and the FAQ) itself?
[16:25] <mdiggory> I will challenge, that getting Fedora and DSpace communities working together will take "coming to the center" on both sides.
[16:25] <kshepherd> it sounds like a logical step, i'm not sure how much use i can be though, aside from testing etc..
[16:26] <tdonohue> mdiggory -- I agree on both points
[16:26] * mhwood still trying to grasp *why*, but the FAQ looks like it will help.
[16:26] <PeterDietz> I'm not familiar with how fedora works, but its looks like build integration on many fronts (compatible data / AIPs, code talks with it, ...)
[16:26] <mdiggory> unfortunately the fedora meeting time is a big conflict for me or I would be there on a weekly basis.
[16:27] <tdonohue> mhwood: does this help at all with the "why"? http://wiki.dspace.org/confluence/display/DSPACE/DSpace-Fedora+Integration+FAQ#DSpace-FedoraIntegrationFAQ-Whataretheperceivedbenefits%3FWhydothisintegration%3F
[16:27] <kshepherd> fedora meetings are all over skype, correct?
[16:27] <tdonohue> mhwood: or does that not begin to answer your questions? (If not -- that's good feedback)
[16:27] <grahamtriggs> I have thoughts, but I'm trying to shape them into a coherent whole
[16:27] <tdonohue> kshepherd -- yes, fedora meetings are on skype right now
[16:28] <mdiggory> so if there were a way to get something scheduled that was specifically tailored for creating a forum for discussion between the two groups, it would promote more collaborative discussions
[16:28] <mdiggory> yes, they are conference calls, little is done in IRC actaully.
[16:28] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[16:29] <mhwood> tdonohue: third major bullet begins to address why nondevelopers might want this. I'll study the whole thing.
[16:29] <tdonohue> yes, I agree -- we definitely need to find ways to promote more discussion between both groups (Fedora & DSpace) and come to a "middle ground" -- some of this, we hope to start figuring out at OR10.
[16:29] <mhwood> Ah, I need to figure out how to make Skype work. I'd wondered why there was almost nothing on IRC at those meetings.
[16:30] <tdonohue> though, I'm sure much of this work will be ongoing for a while -- it's not something that will happen overnight, but we'd like to work towards it
[16:30] <tdonohue> mhwood -- yes, would be good to hear your thoughts once you've had a chance to fully review
[16:31] <kshepherd> cool. if any "collaborative meetings" start to be organised, i'd just like to vote for IRC over Skype, because it's (a) loggable, (b) i can be in a meeting while attending another meeting at work, (c) i think it's just easier for newcomers to join in and share ideas/ask questions, (d) nobody will be confused by my ridiculous accent ;)
[16:32] * mhwood would prefer written meetings too, but will adapt as needed.
[16:33] <tdonohue> yep -- I'd agree... I think we'll definitely need to solve the communication issues, etc.
[16:34] <tdonohue> I guess I was more looking to see if people think this seems like a good initiative (we can figure out the specific details later, and some of them will hopefully start to take shape at OR10)
[16:34] <mdiggory> I challenge though, that the activities in our community are already happening in the GSoC projects, and these projects cannot wait for OR10 to arrive
[16:35] <tdonohue> (the other question is whether this FAQ is clear enough -- keeping in mind that it's audience is a general DSpace user, not necessarily a developer/committer)
[16:35] <mdiggory> it would have been ideal to have a Fedora team member as an observer/mentor to consult with on these projects
[16:36] <kshepherd> true..
[16:36] <tdonohue> mdiggory -- sure, we can talk to Chris Wilper to see if they have anyone who can help or consult
[16:36] <tdonohue> mdiggory -- do you want to send an email to Chris & I? Or should I send it?
[16:38] <carynn> might be useful to have a very quick description of the two frameworks (dspace and fedora) - just to provide some context for non-developers
[16:38] <mdiggory> It would be good maybe if you did it.
[16:38] <mdiggory> Its challenging to to talk about it without involving the topic of development / commiter, because DSpaceand Fedora integration is about combining them at the developer level as tools and packages, specifically , sharing and reusing code, agreeing on development best practices and alignment on platform and third party technologies
[16:38] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:38] <tdonohue> mdiggory -- ok i can send an email to Fedora folks & copy you in
[16:39] <mdiggory> thank you
[16:39] <mhwood> So then, what's in it for sites is that developers work faster?
[16:39] <tdonohue> carynn -- good suggestion, thanks
[16:41] <tdonohue> mhwood -- essentially, what's in it for sites is (1) the extra features it could offer (which Fedora or similar could enable), and (2) the DSpace + Fedora developer pools will start to overlap more -- potentially allowing for more devs to pull from for larger projects, etc
[16:42] <tdonohue> As mdiggory mentioned, we've already essentially started to move in this direction -- DSpace 2 data model was (and this is simplifying things, I know) somewhat similar to a Fedora-like model -- doesn't it make sense not to work together in that sense
[16:42] <mhwood> (2) is basically what I said: dev.s become more productive. Not bad, but is it compelling (for the nondeveloper)?
[16:43] <tdonohue> potentially...for (2) it could mean more UI-based features (if for instance, the DSpace Dev team didn't have to worry as much about backend storage stuff, and they could concentrate more on DSpace workflows and UI features, etc)
[16:44] <carynn> i would probably stress that this puts us more in line with the "semantic web"... as it's framed now, it seems (again, from the non-developer pov) that this is basically a way for dspace to change the way the bitstreams and metadata are stored (i.e. kind of like another option to a srb)
[16:45] <carynn> (btw - i totally understand that this isn't what's happening... just providing a potential pov)
[16:45] <mhwood> I worry that people will think, we spend a lot of time adjusting our uniforms instead of playing, and now we are proposing yet another period of adjustment. Good things are coming along at the same time, but we need for people to readily see that.
[16:47] <tdonohue> mhwood -- I'd actually see this as us finally "playing" -- for many years we've just been "adjusting our uniforms" around "2.0" and a better data model. This is a plan towards a better data model (which is in line with the past 2.0 prototype work) --- it's also not something that's going to suddenly happen overnight, this is a roadmap
[16:47] <mdiggory> At the funding / decision making level, it reduces the competition between the two communities, alignment and consolidation of technologies means more users and less "politics" in making a choice of platform. It also eliminates the mistaken assumption that you choose either "dspace" or "fedora"
[16:47] <tdonohue> good point, mdiggory
[16:48] <carynn> mdiggory: which means, at the user level, it gives me a little more flexibility (i.e. i can choose a fedora module that i really like, even though i want to install dspace)
[16:48] <tdonohue> and, essentially, this is also one of the reasons DuraSpace even exists
[16:48] <tdonohue> DSpace and Fedora have been realizing for a while that there is overlap in their missions, and increasing overlap in their codebases (esp with 2.0 + Fedora) -- hence DuraSpace
[16:49] <robint> mdiggory: Playing devils advocate a bit but competition can be healthy.
[16:50] <tdonohue> I feel like I'm now arguing a point -- and I really don't mean to be (sorry if it seems I am). I'm all for open discussion & playing devil's advocate...i'm just trying to see what the real concerns are, or if there are other ideas to bring forth instead
[16:50] <mhwood> Yeah, but that's all internal to the project(s). I can imagine a lot of people wondering, "so, how will this help to get sooner to a state where things are sorted the way we expected them?"
[16:51] <tdonohue> ok -- i understand the point, mhwood. Yea, we aren't suggesting we suddenly *stop* making DSpace better and work entirely on DSpace on Fedora. I think all of this will happen gradually over time
[16:52] <robint> mhwood: I agree. I ran this past various repo managers and librarians here and the response was underwhelming. They will get interested when they see versioning (for example). They care less about how we achieve it.
[16:52] <tdonohue> So, we should continue to fix issues with DSpace...we aren't stopping one thing and putting all efforts elsewhere
[16:52] <stuartlewis> Not sure if this is relevant - but I showed the FAQ to a few people who know a bit about repositories, but are not DSpace/Fedora experts. They all understood the concepts, and heartily agreed that it seemed a good way forward.
[16:52] <mhwood> But it's more than that; it's another demand on developer bandwidth. It will slow down things end-users want, for a while. Eventually development should be more productive than before, but that's eventually. What do we offer in the shorter term?
[16:53] <tdonohue> robint -- that is interesting
[16:53] <mdiggory> where in this topic did we get an idea that we would stop improving DSpace?
[16:53] <kshepherd> the success of the GSOC project and any pilots/case studies involved with it might clear up some of these concerns
[16:54] <mdiggory> Or that we have to stop working on DSpace to begin to benefit from tools that the Fedora community has developed
[16:54] <tdonohue> kshepherd -- good point. we are hoping the GSOC projects will be successful, and at least provide a template/prototype for how we could move towards this idea.
[16:55] <tdonohue> we also have a very "high-level" 5-step process mapped out here: http://wiki.dspace.org/confluence/display/DSPACE/DSpace-Fedora+Integration+FAQ#DSpace-FedoraIntegrationFAQ-WhataretheplansforintegratingtheDSpaceapplicationwiththeFedorarepositoryplatform%3F
[16:55] <mdiggory> TBH, the Solr discovery work is based on success using solr not only int he Fedora communities, but also int eh Blacklight communities
[16:56] <tdonohue> As you can see from that high-level 5 step process, #1 & #2 are already being worked on in some way -- it's a matter of slowly but surely planning/developing the others. (And this may happen over several releases -- maybe 1.7 includes #1 and part of #2, ...1.8 includes a bit more, etc. etc.)
[16:56] <tdonohue> I see it as a longer term roadmap (though not too long of term, as we do want to get it done...but, it's not on a timeframe to get finished this year)
[16:57] <PeterDietz> Which means we'll need to do some planning for whats in it for me in 1.7 sometime in the future
[16:58] <tdonohue> yep...PeterDietz, exactly. I'm definitely hoping the AIP capibility (#1 in that list) will be ready and approved -- I'll be suggesting some Trunk changes in the next week to help enable that...
[16:59] <tdonohue> ack...well...look at the time.
[16:59] <tdonohue> any last thoughts? I want to turn this over to the GSoC Unit Test project soon
[16:59] <PeterDietz> Cool, I'm still confused with AIP.. In particular how to offline the idea of communities / collections
[17:00] <tdonohue> PeterDietz: it's already "working' (to a point) -- have a read through the wiki page when you get a chance: http://wiki.dspace.org/confluence/display/DSPACE/AipBackupRestorePrototype
[17:00] <mdiggory> I'm looking more at framework/architecture.... The improvements we need to continue to do, especially for 1.7 are in preparing DSpace for being able to plug in other tools and technologies under the hood
[17:01] <tdonohue> Ok --well, I think this has been a good initial discussion. I'd really encourage you all to ask further questions, voice concerns, play devil's advocate, etc.... maybe we should move all this discussion to dspace-devel and open it up further
[17:01] <mdiggory> the work that needs to happen in 1.7 isn't "add fedora", its. what needs to change in what DSpace currently does so others can add fedora if they want to
[17:01] <kshepherd> yes, even ignoring "fedora" for a moment, pluggable storage is good
[17:02] <tdonohue> yea -- I'd say we definitely don't want to "add fedora" in 1.7 -- we won't be fully ready...but, pluggable storage is good.
[17:02] <tdonohue> Ok -- I'll close this meeting now. I'll start a thread on dspace-devel about this idea -- please bring your thoughts/ideas there.
[17:02] <mhwood> Thanks!
[17:03] <kshepherd> cheers all
[17:03] <tdonohue> Thanks all! Stick around for the GSoC Unit Testing meeting (this could also be at least partially ready for 1.7 -- hopefully!)
[17:03] <stuartlewis> We hope so! :)
[17:03] <tdonohue> (that is-- stick around if you can!)
[17:03] <mhwood> I wish I could stay....
[17:03] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:03] * PeterDietz goes into lurk mode.
[17:04] <stuartlewis> OK - a quick recap from our last meeting two weeks ago:
[17:04] * bojans (~Bojmen@91.118.65.110) has joined #duraspace
[17:04] * stuartlewis digs into his email...
[17:05] <mdiggory> Continuing briefly ... we've used pluggable storage, both rrodgers version and the 2.0 version.... we need to continue the topic from last weeks GSoC meeting about things like how do we use a "StorageService" in DSpace 1.7
[17:05] <stuartlewis> We agreed that the first phase of his project would be to look at getting junit embedded into the maven build process, and start writing some exemplar scripts.
[17:06] <stuartlewis> Pere has now done this, and has committed his work to an svn branch if you want to try it out.
[17:06] <stuartlewis> It seems to work fine.
[17:06] <pvillega> (please try it! )
[17:06] <stuartlewis> http://scm.dspace.org/svn/repo/sandbox/gsoc/2010/testing/
[17:06] <stuartlewis> So we have two things to discuss today:
[17:07] <stuartlewis> 1) What we think of his current work - is any of it ready to merge back into trunk, or does it need more work
[17:07] <stuartlewis> 2) Where next?
[17:07] <stuartlewis> If we talk about #1 first.
[17:07] <stuartlewis> Any comments on the work so far?
[17:08] <stuartlewis> Here's some specific examples: http://scm.dspace.org/svn/repo/sandbox/gsoc/2010/testing/dspace-api/src/test/java/org/dspace/content/
[17:09] <pvillega> I explained a bit the tests on the mail to the GSOC list and added information in the wiki, but I can clarify any questions you may have
[17:10] <tdonohue> (i'll admit, I haven't had a chance to review Pere's work yet -- just haven't had the free time, unfortunately)
[17:11] <pvillega> (tdonohue: no problem, we have still 2 months )
[17:11] <PeterDietz> Another way to see the changes is through fisheye: http://fisheye3.atlassian.com/changelog/dspace/sandbox/gsoc/2010/testing?max=30&view=all
[17:11] <stuartlewis> No problem - we can leave it a week or so to give people time to try it, then decide if we want to merge any/all of it into trunk.
[17:12] <bojans> I haven't much time to check the code too, but have general question.. maybe naive but it is still a question :)
[17:12] <bojans> So do you use some test data set for running tests?
[17:12] <tdonohue> stuartlewis -- might be good to send an email to dspace-devel at some point about it too -- maybe a slightly wider audience?
[17:12] <stuartlewis> (just to highlight the work Pere has been doing, fisheye says: Net change in LoC this week: 7,963. Nice!)
[17:13] <stuartlewis> tdonohue: Ok - will do.
[17:13] <stuartlewis> bojans: Not really yet, which is why we should probably move onto #2 now.
[17:13] <stuartlewis> Where next?
[17:13] <tdonohue> another question (if I may): any thoughts on Aaron Z's suggest about avoiding heavy use of mocks, and trying an in-memory DB instead?
[17:14] <PeterDietz> I think that GSoC / GWoC (depending on your hemisphere) is a good use case for using reviews in fisheye
[17:14] <pvillega> bojans: right now, for the unit tests that don't depend on the db, I've used some custom data, for example for DCDate. About the other classes and a DB in-memory, I think Stuart wanted to talk about it
[17:14] <stuartlewis> Pere and I have been talking, and we're wondering if the best next step is to start working on an embedded db so that the tests can be better.
[17:14] <stuartlewis> Without this, the tests will be limited.
[17:14] <stuartlewis> Aaron gave a good overview of this:
[17:15] <mdiggory> I think I'm more interested in Arrons recommendation to focus on getting the embeded db working is a really strong point
[17:15] <tdonohue> PeterDietz -- nice idea, if we can get some 'code reviewers' onboard
[17:15] <stuartlewis> Aaron: I also strongly recommend you do not make heavy use of per-test mocks.
[17:15] <stuartlewis> These tend to make the test writing cost a lot higher and in the end
[17:15] <stuartlewis> they don't test much code. With a system like dspace where most of the
[17:15] <stuartlewis> work is in data fetching and handling you end up hardly testing the
[17:15] <stuartlewis> core functionality of the system if you mock everything.
[17:15] <stuartlewis> I also strongly recommend you consider an in-memory DB rather than
[17:15] <stuartlewis> ignoring the DB in your tests. It is very fast and gives you much more
[17:15] <stuartlewis> useful and reliable test results. This is my favorite:
[17:15] <stuartlewis> http://www.h2database.com/html/main.html
[17:15] <tdonohue> i'd agree with everyone else -- I like Aaron's recommendation of an in-memory DB
[17:16] <stuartlewis> Cool - so it all sounds like we're in agreement?
[17:16] <stuartlewis> If so, do we have any preference for a db?
[17:16] <stuartlewis> h2 / derby / hsql
[17:16] <pvillega> I think Aarons proposal is good, h2
[17:16] <tdonohue> aaron's recommendation seems fine (I have no real preference)
[17:16] <mdiggory> enabling the testing in trunk is something that should be ported in as early as we can, it will get you more direct feedback
[17:16] <stuartlewis> Ditto - I have no experience with any, so trust Aaron.
[17:17] <mdiggory> bth all three
[17:17] <bojans> me too, h2 +1
[17:17] <stuartlewis> Pere - are you happy with that?
[17:17] <pvillega> sure
[17:17] <stuartlewis> If so, how long do you want to do this work before we meet again to review it?
[17:17] <stuartlewis> 3 weeks again?
[17:18] <mdiggory> the dspace 2.0 stuff uses both derby and hsql
[17:18] <stuartlewis> mdiggory: Do you have a personal preference?
[17:18] <pvillega> mmm let's do one thing, let me work on it as right now i'm not sure how it will go (I had some unforeseen issues with mocks)
[17:18] <mdiggory> and Elliots work utilized both if I recall
[17:18] <pvillega> I will send you a status update by next Monday and we can decide then?
[17:19] <mdiggory> not in the db choice, in the abstraction choice
[17:19] <stuartlewis> OK - So perhaps if you do some exploratory work over the next week, report back, and we can make a decision?
[17:19] <stuartlewis> Excellent.
[17:19] <pvillega> ok, sounds like a plan
[17:20] <stuartlewis> Back to number 1 - I'll send an email to dspace-devel with a proposal (perhaps stick it in jira with a patch) for which parts of Pere's branch we want to commit soon, and we can review it there?
[17:20] <stuartlewis> I suspect we'll definitely want the infrastructure, and then we can review each test individually.
[17:21] <stuartlewis> Does that sound OK?
[17:21] <pvillega> on point #1, I would say it will be more useful once we have the in-memory dba
[17:21] <tdonohue> stuartlewis: sounds good -- if you want, we could even add as a discussion point in one of next Dev mtgs (though I'd want you to lead it, if you would)
[17:21] <pvillega> as right now many unit tests work against mocks, which defeats the purpose
[17:21] <pvillega> although reviewing the code now would be good
[17:21] <stuartlewis> pvillege: That's why I was thinking of getting the framework in, then add the tests later?
[17:21] <stuartlewis> Or is the framework likely to change dramatically once you get the db integrated?
[17:22] <stuartlewis> tdonohue: Sounds good.
[17:22] <tdonohue> stuartlewis: ok -- just let me know (offline) which meeting you want to add it to, and can be at
[17:22] <pvillega> stuartlewis: probably a bit, I might be able to remove several mocks
[17:22] <mdiggory> for instance, we will want to abstract the postrgres sql into something that we can produce derby / hsqldb ddl.... this is what I mean by abstraction, the way that elliot used http://db.apache.org/ddlutils/
[17:23] <pvillega> mdiggory: where can I see this work? On DSpace services?
[17:23] <stuartlewis> OK - maybe we'll wait for now then, and review it again once we have some db code in there.
[17:24] <pvillega> stuartlewis: there is some "demo database" with preexisting data available somewhere?
[17:24] <stuartlewis> But I agree with mdiggory that getting some code into trunk sooner rather than later will help the review process as well as being good for the project and for DSpace development in general.
[17:25] <mdiggory> that reference is in your wiki page pvillega
[17:25] <stuartlewis> pvillega: No, but creating one would be good. Perhaps we could build it by shipping with a struct builder file, and a set of item import datasets?
[17:25] <pvillega> ok, sorry, getting confused with so many links and info :D
[17:26] <mdiggory> http://presentations.dlpe.gatech.edu/proed/or09/or09_052009_4/index.html
[17:26] <pvillega> stuartlewis: yes, I will create one for the tests, no problem.
[17:26] <mdiggory> but I think we need to get Elliot to give up the svn location again
[17:26] <PeterDietz> You could have a postgres db-dump in svn, and just load that before running tests.. Then tests can run against a regular instance
[17:27] <stuartlewis> Would building the database from sources (e.g. item imports / strcut builder) be better as it is db agnostic, which leads to another level of testing?
[17:27] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[17:27] <stuartlewis> (and is db dump version agnostic)
[17:27] <mdiggory> PeterDietz: you could probibly abstract that into ddlutils as well so it can load into other dbs
[17:28] <kshepherd> my searching for Elliot's svn area gives me https://svn.mse.jhu.edu/repos/public/dspace/branches/unit-testing/
[17:28] <pvillega> i will check ddlutils and the import/struct builder paths
[17:28] * stuartlewis hasn't seen ddlutils before - looks very useful (thanks mdiggory)
[17:30] <stuartlewis> So - to conclude? Any further input today?
[17:30] <stuartlewis> Pere has a new to-do list: he'll investigate db options and report back in a week or so, we can make any decisions if needed, and move ahead with that.
[17:31] <pvillega> yes, one thing before I forget! The package org.dspace:dspace-ui-shared:war:1.6.1-SNAPSHOT is till missing from the maven repository, so when running "mvn test" it fails. It's not critical, but as we have disabled tests when running "mvn package", it would make life easier :)
[17:32] <stuartlewis> Thanks everyone for coming along and joining in - much appreciated :)
[17:32] <stuartlewis> Meeting over!
[17:32] <pvillega> Thanks for coming! :)
[17:33] <mdiggory> sorry, I'm actually back now :-)
[17:34] <mdiggory> pvillega: What we need is a hudson instance doing deployments of trunk...
[17:34] <pvillega> yes, that would we nice
[17:36] <PeterDietz> It would be nice to have dspace runnable on google app engine
[17:37] <mdiggory> but AMT I am running your deploy
[17:37] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:37] <stuartlewis> I tried getting a SWORD client to run on GAE. It all went well, until I tried making http calls. Google mess with the java.net packages a *lot* :(
[17:38] <mdiggory> I've been working on the side on porting the maven repository over to sonatype
[17:38] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[17:38] <mdiggory> this will make deploying / releasing cleaner, but we have to be stricter in our pom files
[17:39] <mdiggory> I've got successfull tests, but we need to stop using third party repositories among other things...
[17:40] <mdiggory> dspace-ui-shared is now deployed.....
[17:42] <pvillega> mdiggory: it works, thanks, but now this one is missing: org.dspace:dspace-xmlui-webapp:war:1.6.1-SNAPSHOT
[17:43] <mdiggory> thats still deploying
[17:43] <pvillega> ah ok :)
[17:44] <stuartlewis> kshepherd / tdonohue: Just re-reading the bits of the dev meeting I missed. What was it you wanted me to do?
[17:44] <stuartlewis> tdonohue: kshepherd (or stuartlewis) -- any updates on 1.6.2 status? Should we set a "date" / make an official announcement?
[17:44] <stuartlewis> [08:08am] kshepherd: tdonohue: I haven't recieved a patch for DS-584 yet, but it seems as though all we really need to do is "UNIXify" the start-handle-server script you uploaded
[17:44] <stuartlewis> [08:08am] kshepherd: so if i haven't heard from stuart by later this afternoon i'll do that myself, hopefully should have a few free minutes today since i started early
[17:44] <tdonohue> stuartlewis -- oh not much, just everything going forward
[17:44] <tdonohue> (kidding) :)
[17:44] <stuartlewis> Easy! :) I'll have it done by lunch time! :)
[17:45] <tdonohue> I think kshepherd was expecting you to commit the patch to DS-584 (I just haven't had time to do it) -- I think that was it
[17:45] <tdonohue> so -- he mentioned that if he hadn't heard from you about DS-584, he'd just do it later on
[17:46] <stuartlewis> OK - happy to do it.
[17:46] * stuartlewis fires up IDEA
[17:46] <tdonohue> excellent...thanks!
[17:49] <kshepherd> oh cool thanks stuart :)
[17:49] <kshepherd> just don't forget those linebreaks ;)
[17:50] * robint (~52292565@gateway/web/freenode/ip.82.41.37.101) Quit (Quit: Page closed)
[17:59] * bojans (~Bojmen@91.118.65.110) Quit (Remote host closed the connection)
[17:59] <mdiggory> pvillega: the deployment has finished
[18:01] <stuartlewis> Patch done, but before I commit, need to do the hard bit!
[18:01] <stuartlewis> Who to credit it to in CHANGES! :)
[18:01] <stuartlewis> So far I have:
[18:02] <stuartlewis> (Tim Donohue, Kim Shepherd, Stuart Lewis)
[18:02] <stuartlewis> - [DS-584] start-handle-server script broken - Error in launcher.xml: Invalid class name
[18:02] <stuartlewis> Anyone else?
[18:02] <stuartlewis> Keith G?
[18:05] <stuartlewis> tdonohue / kshepherd: Anyone else?
[18:06] <tdonohue> umm... i actually don't know -- kshepherd? (I imagine you should put in keithg, he helped with testing)
[18:09] <stuartlewis> I've committed the patch now.
[18:09] <tdonohue> thanks!
[18:09] <stuartlewis> It fires up ok on my machine (just doesn't run as such as I have not config dct file)
[18:10] <stuartlewis> Suppose I better apply it to trunk too before closing the issue....
[18:13] <kshepherd> heh i'd replace my name with keith's in CHANGES
[18:13] <kshepherd> i was just testing really, he caught it and first suggseted solutions
[18:15] <stuartlewis> Too late! :p
[18:16] <stuartlewis> We like to share the love!
[18:25] <pvillega> mdiggory: it works, thanks a lot!
[18:25] <pvillega> good night people
[18:25] * pvillega (~pvillega@89.100.155.181) Quit (Remote host closed the connection)
[18:26] <PeterDietz> I found a video on DSpace/Fedora collaboration, suggesting running DSpace with Fedora inside http://crigshow.blogspot.com/ -- two years ago. The audio is kind of bad, too quiet and too loud..
[18:36] <tdonohue> Yea - this has been an ongoing topic for years now -- just never really brought to the "forefront" or fully "approved"
[18:39] <tdonohue> interesting fact: that "DSpace/Fedora Collaboration" press release was actually part of the starting of DuraSpace
[18:42] * carynn (~cneiswen@c726.staff.lib.uci.edu) has left #duraspace
[18:51] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[19:05] * StephenGWills (~anonymous@cpe-66-65-233-205.nycap.res.rr.com) has joined #duraspace
[19:25] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[19:34] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:32] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Ping timeout: 258 seconds)
[21:07] * achelous (~tom@216.160.210.151) Quit (Ping timeout: 240 seconds)
[21:37] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[21:38] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[21:42] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Ping timeout: 276 seconds)
[21:42] * mdiggory_ is now known as mdiggory
[22:00] * achelous (~tom@174-126-228-87.cpe.cableone.net) has joined #duraspace
[22:04] * achelous (~tom@174-126-228-87.cpe.cableone.net) Quit (Remote host closed the connection)
[22:07] * achelous (~tom@174-126-228-87.cpe.cableone.net) has joined #duraspace
[23:58] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.