Timestamps are in GMT/BST.
[0:00] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Ping timeout: 248 seconds)
[0:02] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) Quit (Quit: Leaving.)
[0:10] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[1:56] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[2:01] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[2:04] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Ping timeout: 264 seconds)
[2:04] * mdiggory_ is now known as mdiggory
[2:46] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[2:49] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Ping timeout: 265 seconds)
[2:49] * mdiggory_ is now known as mdiggory
[3:43] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[4:06] -leguin.freenode.net- *** Looking up your hostname...
[4:06] -leguin.freenode.net- *** Checking Ident
[4:06] -leguin.freenode.net- *** No Ident response
[4:06] -leguin.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:14] * pvillega (~pvillega@86.47.50.67) has joined #duraspace
[4:18] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[5:37] * pvillega_ (~pvillega@86.47.50.67) has joined #duraspace
[5:38] * pvillega (~pvillega@86.47.50.67) Quit (Read error: Operation timed out)
[8:38] * pvillega__ (~pvillega@62.77.170.185) has joined #duraspace
[8:42] * pvillega_ (~pvillega@86.47.50.67) Quit (Ping timeout: 276 seconds)
[9:23] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:26] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[9:51] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[9:56] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) has joined #duraspace
[9:58] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[10:02] * pvillega__ (~pvillega@62.77.170.185) Quit (Ping timeout: 252 seconds)
[10:08] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[12:07] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[12:30] * pvillega (~pvillega@62.77.170.185) Quit (Remote host closed the connection)
[12:33] * achelous (~tom@216.160.210.151) Quit (Remote host closed the connection)
[12:53] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[13:52] * achelous (~tom@216.160.210.151) has joined #duraspace
[14:12] * achelous (~tom@216.160.210.151) Quit (Quit: Lost terminal)
[15:03] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[15:04] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:04] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:35] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[15:45] * carynn (~cneiswen@c726.staff.lib.uci.edu) has joined #duraspace
[15:55] * robint (~52292565@gateway/web/freenode/x-ysegcasoxlqkpplr) has joined #duraspace
[16:00] <tdonohue> Hi all. DSpace Dev Mtg is about to get started. Agenda is up at: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-06-02 If you have any agenda items to add, send me a msg..
[16:01] <tdonohue> First up... GSoC updates -- GSoC has gotten started, and I know at least a few of the projects are already moving along.
[16:02] <tdonohue> If anyone is interested in taking part in (or giving feedback to) the Unit Testing project, they are meeting tomorrow at 21:00 UTC
[16:02] <tdonohue> http://www.fedora-commons.org/confluence/display/DSPACE/GSOC10+-+Add+Unit+Testing+to+Dspace
[16:03] <tdonohue> mdiggory -- do you have any updates to add?
[16:03] <mdiggory> Hi
[16:04] <mdiggory> We are trying to organize a GSoC discussion meeting to occur after the commiter meeting today, But I am unsure if everyone can make it given timezones
[16:04] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[16:05] <mdiggory> The goal of the meeting is (1) make sure we are getting students to complette the setup tasks they need
[16:05] <mdiggory> and (2) discuss collaborative / architectural relationships between storage services, semantic store and (possibly even AIP prototype)
[16:06] <mdiggory> and how there may impact 1.7 and the REST project
[16:07] <tdonohue> sounds good
[16:07] <tdonohue> also, reminder, most of the GSoC discussions take place on the public 'dspace-gsoc-student' list: https://lists.sourceforge.net/lists/listinfo/dspace-gsoc-student So, feel free to join if you haven't already
[16:08] <mdiggory> yes, do join if your interested in participating in mentorship activities...
[16:09] <tdonohue> or, even if you are just interested in giving feedback, etc. several of these projects have goals to end up with "committable code", which could possibly be ready for 1.7 (assuming all goes well)
[16:09] <mdiggory> I would like to reach out at this point and talk about the collaborative aspects of the projects we are seeking to kindle.
[16:10] <tdonohue> go ahead, mdiggory...
[16:10] <mdiggory> We are at a critical point in the period where existing developer input is critical
[16:11] <mdiggory> The directions of the 2 storage related projects will need input for the community to assure their direction is correct
[16:11] <mdiggory> and also so that the community is aware of their existence.
[16:11] <mdiggory> This falls somewhat on my shoulders as mentor
[16:12] <mdiggory> and I bring it up here to instigate that some commitment from the community in this area would be reasuring.
[16:12] * 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:13] <tdonohue> maybe for the remainder of the summer, we should make sure we always set aside 15mins or so for GSoC in these meetings (obviously, that's not always enough to get the exact answers/commitment, but at least it will help pull people back in)
[16:14] * jatrimble (~jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[16:14] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:14] <mhwood> Good idea, keeping that work in front of everyone, even if there isn't much to say some weeks.
[16:15] <tdonohue> along with mdiggory, I'd also like to see our developers (committers esp.) make some commitment to keeping up-to-date with the GSoC projects.
[16:16] <tdonohue> I'd also stress again, that the goal is that several (or maybe even all) of these projects could be "trunk-ready", and a part of 1.7 -- so, it's imperative we all stay informed so that we don't cause undue delays if the code is ready to go...
[16:16] * cipad (~cipad@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[16:17] <mdiggory> yes, I think that what I refer to is that if your looking at a project to enhance/alter/modify dspace for 1.7 or a future version as a contribution... that we have a means to (1) make sure your first aware of the GSoC activities and the possibility of participating there if there is overlap and (2) if not, provide some announcements/activities/directions in main channels like listserves and wiki that your activity planning something...
[16:17] * cipad (~cipad@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Client Quit)
[16:18] <mhwood> JIRA
[16:18] <mdiggory> speaking of which... tdonohue I've been reading up on your work around AIP and think that there is an interesting disucssion waiting to happen with the AIP stuff, pluggable assetstore and storage services architecture
[16:19] <tdonohue> yea -- i'd agree -- get your ideas for 1.7 (or beyond) into JIRA
[16:19] <mdiggory> likewise
[16:20] <mdiggory> but will we bloat JIRA with lots of empty placeholder tickets int he process?
[16:20] <tdonohue> mdiggory -- yea, I think there could be some interesting overlap there -- but, I'd stress that the AIP work is currently *external AIPs only* (i.e. no internal storage of these AIPs). So, there may not be as much overlap initially (but could be more later on worth investigating)
[16:21] <tdonohue> (fyi for all...my AIP work is going on here: http://fedora-commons.org/confluence/display/DSPACE/AipBackupRestorePrototype)
[16:21] <tdonohue> As for JIRA -- I'd rather get the word out there -- I don't think it bloats JIRA too much if you put your projects in there -- just assign them to yourself, so that someone else doesn't claim them :)
[16:21] <mdiggory> Yes, I'm talking about the experiences and tooling that may be repurposed or act as a basis for GSoC storage service migration work...
[16:22] <tdonohue> agreed, mdiggory
[16:22] <mdiggory> I realize this may be going into what the next meeting is for... so if theres other material to be discussed... feel free to move forward
[16:23] <tdonohue> ok. As we've started to move towards JIRA discussion, let's discuss the new updates I just enabled. We now have a "Received" step in JIRA workflow (thanks to robint for pushing the idea along). So, new items first are marked "Received"
[16:23] <tdonohue> after someone reviews them, they will then move to "Open" (and hopefully be assigned to someone shortly thereafter)
[16:24] <tdonohue> we also now receive automated reports from JIRA, of "stale issues" (ones that haven't changed in 6+ months), and "issues needing review" (ones in that "Received" state). More info on each, and links to the reports are in the agenda: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-06-02
[16:25] <tdonohue> my question for everyone else is -- is there anything else you'd like JIRA to report to us? (these reports go to dspace-devel -- the first "stale issues" report went out yesterday)
[16:26] <robint> Like the reports. I think it will help prevent backlog.
[16:26] <tdonohue> stuartlewis suggested a possible report of "unresolved issues which are scheduled for the next release" -- which may be another one we'd want
[16:27] <tdonohue> other ideas/thoughts?
[16:28] <robint> I like Stuart's idea but perhaps nearer the time of a release.
[16:29] <PeterDietz> I think its helpful. A potential future one might be a "needs review" / "feedback", however I think in my perspective I'll try to find someone to review something (code) that needs reviewed
[16:31] <mdiggory> +1 for PeterDietz
[16:32] <tdonohue> I agree, robint, that stuart's idea becomes even more useful as we near the next release.
[16:33] <mhwood> That's probably enough for now. We don't want to drown in reports.
[16:34] <tdonohue> ok -- we'll leave it at that for now -- possibly add a release-based report in the future. & we can think more about a "feedback" status, if we all feel it could be generally useful
[16:35] <tdonohue> So -- next up.... do we do a 1.6.2 release? kshepherd & I have discussed this off and on over the last weeks -- DS-584 is a bit of an "ugly bug" for those using the handle-server on Linux
[16:35] <tdonohue> http://jira.dspace.org/jira/browse/DS-584
[16:35] <tdonohue> It might be worth doing a quick-ish 1.6.2 release to resolve this.... anyone else have thoughts on it?
[16:36] * kshepherd just got in
[16:36] * stuartlewis just got here too :)
[16:36] <tdonohue> good timing then, on both parts :)
[16:36] <robint> I dont know if its appropriate but it might be easier to resolve any outstaanding issues with DCDate prior to 1.7
[16:37] <stuartlewis> What would be the downside to release a 1.6.2 that does nothing apart from fix a single bug?
[16:37] <mhwood> None, if it's a troublesome enough bug. I think this one is.
[16:37] <tdonohue> I don't see any downside to a release fixing one bug, assuming we all believe that one bug warrants a very immediate fix
[16:38] <kshepherd> i think it's important enough too
[16:38] <stuartlewis> 1.6.2 +1
[16:38] <tdonohue> 1.6.2 +1 as well
[16:38] <kshepherd> 1.6.2 +1
[16:38] <mdiggory> maintenance releases shouldn;t be about bells and whisles
[16:38] <mdiggory> +1 1.6.2
[16:38] <PeterDietz> 1.6.2 +1
[16:38] <mhwood> +1 1.6.2
[16:38] <robint> 1.6.2 +1
[16:39] <stuartlewis> Motion carried! :)
[16:39] <kshepherd> the ayes have it
[16:39] <tdonohue> ok -- anyone willing to take a lead on 1.6.2?
[16:39] <tdonohue> (i.e. who can take the lead on fixing this bug, and then getting this out soonish)
[16:40] <PeterDietz> I think kshepherd has done a good job with 1.6.1, and he's already figured out the release process, I nominate him to release 1.6.2
[16:40] <kshepherd> lol
[16:40] <stuartlewis> I'm happy to write a patch, but am out the office in meetings all day today :(
[16:41] <kshepherd> honestly, i don't mind doing the release
[16:41] <keithg> lol - I agree on ksheperd's good job, but I was going to nominate Peter :)
[16:41] <kshepherd> but i haven't followed the script launcher changes very closely at all
[16:41] <kshepherd> keithg: ssshhh, we get him back later by nominating him for 1.7
[16:41] <tdonohue> we'll all nominate PeterDietz for 1.7 then
[16:41] <kshepherd> yeah see
[16:41] <keithg> :)
[16:42] <tdonohue> ok...then, 1.6.2 is kshepherd leading with possible help from stuartlewis (on the bug fix)
[16:42] <mhwood> Patch writer and RC don't have to be the same person.
[16:42] <stuartlewis> IN a way the script launcher isn't an issue here, as we can move the 'old' dsrun functionality into the handle start script so it is standalong and has no further dependencies.
[16:42] <tdonohue> I'd say, as soon as we can fix that bug, let's announce and release 1.6.2 (so, hopefully sometime in the next week)
[16:42] <kshepherd> yes, and that was the last workaround we'd discussed too
[16:43] <kshepherd> so ok, i'm happy to release, but i'll need help from stuartlewis, keithg etc. on the best fix for the bug
[16:43] <stuartlewis> OK - will make the patch today or tomorrow.
[16:43] <keithg> I'll help with testing
[16:43] <tdonohue> sounds like a plan then. thanks kshepherd, stuartlewis and keithg!
[16:43] <kshepherd> we have the CNRI handle for demo.dspace.org which should help testing too
[16:44] <tdonohue> umm..yea, that means I gotta get that up and going -- whoops :)
[16:44] <kshepherd> hehe
[16:44] <tdonohue> I'll put that as a high priority and get on that :)
[16:45] <PeterDietz> I will be available enough to nominate myself for 1.7 RC, so that can go forward
[16:45] <keithg> thanks for arranging it
[16:46] <tdonohue> PeterDietz: and I was joking ;) No, seriously, that'd be wonderful if you are willing to be RC for 1.7
[16:46] <stuartlewis> PeterDietz: Excellent :)
[16:46] <robint> Big pat on the back for PeterDietz :)
[16:46] <tdonohue> yea -- now, I think we all owe PeterDietz pizza...
[16:47] <PeterDietz> no no, I'm still on the hook for that one
[16:47] <PeterDietz> still a few logistics to solve
[16:48] <tdonohue> yea...the whole "how to mail pizza and keep it hot" logistic is a tough one
[16:48] <tdonohue> ok -- any other topics for today? we could try and do a mini-JIRA review for the next 10 mins?
[16:49] <stuartlewis> Might as well if there are no other agenda items?
[16:49] <tdonohue> ok, let's try and get through a few old JIRA issues
[16:49] <kshepherd> JIRA review sounds good to me
[16:50] <tdonohue> Eperson netID is lost editing the record from the webUI: http://jira.dspace.org/jira/browse/DS-524
[16:50] <tdonohue> (this one is a bit involved -- but, I'd like to get more feedback for other committers)
[16:50] * jatrimble (~jtrimble@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[16:50] <kshepherd> there seems to be slight disagreement over the desired behaviour here
[16:51] <tdonohue> yea -- robint & I seem on one side, and andrea is on the other. If others have thoughts, I'd love to hear them
[16:52] <mhwood> If you can't trust your Admin, you need a new Admin. It should be editable by Admin.
[16:53] <tdonohue> yea, I'd agree -- I feel we should treat netID similar to email in DSpace
[16:54] <kshepherd> i guess my opinion is: (1) trust admins, (2) once people are getting tricky enough to use netid for stuff other than LDAP/AD, and want to make sure that value isn't edited/lost, they should be able to follow simple workarounds (which we publically document somewhere) like using ldap.enable = true in dspace.cfg
[16:55] <kshepherd> i like the "treat like email" approach
[16:56] <kshepherd> oh, wait, i see the ldap.enable thing is *not* a valid workaround, i misread Andrea's last comment
[16:57] <tdonohue> yea -- there is no good "workaround" right now. we basically need to just make a decision and move forward.
[16:57] <mhwood> Losing information because DSpace is coded that way, is our problem. Losing information because some Admin goofed is a site problem.
[16:57] <tdonohue> so, in the essence of time, please try to add your own thoughts to DS-524 -- this one is "stuck" and needs a consensus to move forward.
[16:58] <tdonohue> one more: Move item - inherit default policies of destination collection: http://jira.dspace.org/jira/browse/DS-525
[16:59] <tdonohue> +1 to DS-525 -- sounds like a nice feature, stuartlewis
[16:59] <kshepherd> this patch is good.. the only reason it wasn't included in 1.6.1 is that it's not a bugfix
[17:00] <mhwood> Agreed, patch as described sounds right.
[17:00] <tdonohue> gotcha -- wasn't sure if it had been reviewed really :)
[17:01] <tdonohue> Ok -- we'll close things up then. Thanks again to kshepherd, stuartlewis & keithg for volunteering to get 1.6.2 going quickly. Thanks also to PeterDietz for volunteering to lead 1.7.
[17:02] <tdonohue> have a good rest of the week all! -- official meeting is closed
[17:02] <mhwood> 'bye all.
[17:02] * pvillega (~pvillega@89.100.155.181) has joined #duraspace
[17:02] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:03] * robint (~52292565@gateway/web/freenode/x-ysegcasoxlqkpplr) has left #duraspace
[17:03] <pvillega> hi, sorry for the delay, problems connecting
[17:04] <mdiggory> Well, I assume I should now take over an see if we can lead a GSoC meeting now :-)
[17:04] <tdonohue> go for it mdiggory -- it's your meeting now -- i'll stick around
[17:06] <mdiggory> So I will go back to where we left off in the commiter meeting which was the following:
[17:08] <mdiggory> The goal of the meeting is (1) make sure we are getting students to complette the setup tasks they need
[17:08] <mdiggory> [1:05pm] mdiggory: and (2) discuss collaborative / architectural relationships between storage services, semantic store and (possibly even AIP prototype)
[17:10] <mdiggory> Sorry for the delay.
[17:10] <mdiggory> I am now flly here.
[17:10] <mdiggory> fully...
[17:11] <mdiggory> Who do we have available for the meeting today?
[17:11] <pvillega> i'm here
[17:11] * PeterDietz is lurking
[17:11] * 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:11] <kshepherd> (i'm lurking)
[17:11] <krnl_> me 2
[17:11] <tdonohue> i'm here -- semi-lurking
[17:12] <mdiggory> krnl_: perhaps your name so anyone who doesn't know your call sign ;-)
[17:12] <mdiggory> krnl_ is Andrius
[17:12] * krnl_ is now known as andriusbl
[17:12] <tdonohue> oh, yea...we probably should all do that :) I'm Tim Donohue from DuraSpace
[17:13] <andriusbl> :)
[17:13] <kshepherd> i'm Kim Shepherd from Outer Space
[17:13] <andriusbl> Andrius Blazinskas - Storage project ;)
[17:13] <kshepherd> actually that's a pretty catchy product name
[17:13] <tdonohue> :)
[17:13] * kshepherd notes that one down
[17:14] <mdiggory> So its a little silly with two developers who already have scm accounts to tell you guys to setup your accounts so we can add you ;-)
[17:14] <kshepherd> heh
[17:14] <pvillega> Pere Villega, unit testing
[17:14] <mdiggory> We will need to get such details together for those who are not here due to schedules and my general disorganization
[17:15] <mdiggory> We currently have you guys creating wiki pages outlining your projects. At some point we should discuss the use of JIRA and the benefits you will get from utilizing it to organize your project issues....
[17:16] <mdiggory> http://jira.dspace.org/jira/secure/Dashboard.jspa
[17:16] <mdiggory> We've setup a space here but I'm not sure yet if it is more valuable to use it or the common JIRA space for dspace
[17:16] <mdiggory> http://jira.dspace.org/jira/browse/GSOC
[17:17] <mdiggory> Ideally, if you want to propose code / changes to dspace trunk, it would be best to approach it in JIRA tickets so that the topics come to the surface in our weekly Commiters meetings.
[17:18] <pvillega> probably the gsoc space is better, will remove the "noise" of daily use of Dspace JIRA
[17:18] <mdiggory> I suspect that otherwise, it is good to track your personal project activities in the GSOC space.
[17:19] <mdiggory> I highly advise using JIRA for your projects management as it gives you an opportunity to gather feedback and details from the comment threads associated with the issue. Likewise, I highly advise that you commit changes with the JIRA ID so that the commits are associated with your tickets in JIRA>
[17:20] <mdiggory> We can create separate components for each project to allow you to separate the activities, however, it may be wise to utilize the components to address coding that may have some commonality between your projects.
[17:21] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:21] <mdiggory> pvillega: I know you are currently working in a sandbox branch, perhaps we can talk about andriusbl's project/workspace needs?
[17:21] <pvillega> fine :)
[17:21] <mdiggory> andriusbl: Last year you utilized the dspace-fedora project space in the modules directory for your work,,,
[17:22] <andriusbl> yup
[17:22] <mdiggory> http://scm.dspace.org/svn/repo/modules/storage-fedora/
[17:22] <andriusbl> this year i'll need something more
[17:23] <mdiggory> I did do the honors of "extracting" significant portions of the dspace2 codebase over the last week in an effort to break those out of the oder dspace2 build
[17:23] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-database/
[17:23] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-storage/
[17:24] <mdiggory> I also did some initial testing of this in the storage-db project.
[17:24] <mdiggory> http://scm.dspace.org/svn/repo/modules/storage-db/branches/dspace-storage-db-2.0.x/
[17:25] <mdiggory> the goal being to get the JUint testing to at least work on the original dspace2 codebase but without dependency on the dspace2 project, instead dependency on the dspace-services project
[17:26] <mdiggory> so this is IMO, something that we (the dspace2 developers) should provide to the community to get the dspace2 codebase to a point that GSoC students can utilize it
[17:27] <mdiggory> but I digress... andriusbl this is just pointing out the areas of the scm that you will want to be focused on.
[17:27] <mdiggory> While these are "extracted" they are limited in features and implementation... likewise in usage...
[17:28] <mdiggory> and thats one of the areas that we hope to see you pickup the reigns
[17:28] <andriusbl> yes, i understand that
[17:28] <andriusbl> i've checked them out
[17:31] <mdiggory> I will try to organize the next meeting time to allow for Yigang to also be available to discuss how we may want his work to overlap with yours. I suspect that this overlap might be best served by looking at the Mulgara parts (RI) of Fedora and how we may access them for use in the StorageService... Ideally, Semantic Storage is not that far removed from Fedora storage.
[17:32] <andriusbl> well, i believe the main overlap will be basically interfaces used
[17:34] <mdiggory> Yes, that will, I expect, be the case
[17:34] <mdiggory> I likewise suggested to tdonohue in the last commiters meeting, that looking at the AIP prototype may give us some ideas around how to address the storage of Communities/Collections etc in a Fedora backed StorageService
[17:34] <andriusbl> i will try to make dspace-storage functional in dspace 1.x and he will use them
[17:34] <carynn> hi, everyone~ sorry to be late in joining... I'm Caryn, from Univ of California, Irvine
[17:34] <mdiggory> I think there is even more in question in terms of dspace-storage
[17:34] <mdiggory> hello carynn
[17:35] <andriusbl> yes
[17:35] <mdiggory> I believe we are not even sure yet how one should integrate the dspace-storage service of dspace2 into dspace 1.x
[17:35] <andriusbl> i think on my part, we need to agree on something I should start from
[17:36] <andriusbl> we have dspace-database, dspace-storage separated here
[17:36] <mdiggory> The biggest question for DSpace 1.x is what will happen to "DSpaceObject"
[17:37] <mdiggory> Is DSpaceObject something we will back by dspace-storage or is it something we will "cover over" by dspace-storage
[17:38] <mdiggory> I.E. do you create a LegacyDSpaceStorageService? Or do you gut DSpaceObejct and wire in StorageService as its Implementation?
[17:39] <andriusbl> maybe firt one sound better
[17:39] <andriusbl> first
[17:39] <mdiggory> And though we do not also have Bojan here... this impacts how one would implement dspace-rest on dspace 1.7
[17:40] <mdiggory> andriusbl: if that is the case, then we need to look much more closely at the work Bojan did last year
[17:41] <mdiggory> where he implemented EntityProviders for many of the DSpaceObjects....
[17:41] <andriusbl> i'm not sure yet, maybe i'll need to take a deeper look
[17:41] <mdiggory> I'll get you a link...
[17:41] <mdiggory> http://scm.dspace.org/svn/repo/modules/rest/branches/dspace-rest-1.x/src/main/java/org/dspace/rest/providers/
[17:41] <carynn> just curious... what do you see as the benefit of creating a LegacyDspaceStorageService?
[17:42] <mdiggory> carynn: its a chicken or egg issue really....
[17:43] <carynn> that's what i was wondering... if you insert a new storage service, don't you also sort of create something that you will eventually need to cut ties with? (iow, gutting and wiring in new implementation is cleaner?)
[17:43] <mdiggory> In its simplest definition the idea behind the DSpace StorageSerivce was to make accessing a DSpaceObject consistent
[17:43] <mdiggory> Only, the Concept of a DSpaceObject changed its terminology by the time we got moving forward in creating dspace2
[17:44] <mdiggory> and we started calling them "StorageEntities"
[17:44] <mdiggory> We tore apart the DSpace 1.x data model and attempted to identify more granular Datastructures that were in common
[17:45] <andriusbl> that depends whether one wants DSpaceObject be left in api code or not
[17:45] <mdiggory> we came up with "Entity", "Property" and "Relation"
[17:45] <tdonohue> so, one thing to think about -- which option will require less overall changes to the current Trunk code (and the future 1.7 work). Since so much code (at many levels) interacts with DSpaceObject, you might want to avoid having to rewrite/rework all that code
[17:45] <mdiggory> so in that case tdonohue ...
[17:46] <mdiggory> you comment suggests a LegacyStorageService implementation that "shims" the legacy datamodel.
[17:46] <mdiggory> and the that shim is used in the UI and APPs rather than the DSpaceObjects....
[17:47] <mdiggory> (incrementally, over time)
[17:48] <mdiggory> The challenge with doing this is that we do not get immediate benefit of the StorageService as a means to swap out the underlying functionality of the existing DSpaceObjects
[17:48] <mdiggory> and thus not much initial benefit in 1.7
[17:49] <mdiggory> the work only sets the stage for future refactorings
[17:49] <tdonohue> yes -- I was just noticing that a search on "DSpaceObject" on trunk brings a result of 163 different Java files using it -- spread all over,API, XMLUI, JSPUI, LNI, OAI, SOLR, etc.
[17:49] <tdonohue> I was just hoping you weren't planning to have to replace all those usages of DSpaceObject in one summer :) (which sounds a bit daunting to me)
[17:50] <mdiggory> I understand the fear/risk
[17:50] <mdiggory> we've been down this road with the DAO project perviously
[17:50] <carynn> on some level, it makes sense to do the shim for 1.7, which is supposed to be bug fixes only, right? then, implement the full system in 2.0 (or whatever we call the major update)
[17:50] <tdonohue> carynn -- no, 1.7 is the next major update -- 1.6.1 was bug fixes only :)
[17:51] <mdiggory> carynn: 1.7 is a major relase and not limited to bug fixes
[17:51] <carynn> ah, sorry, missed that...
[17:51] <mdiggory> 1.7, 1.8, 1.9, 2.0 all give us an opportunity to step incrementally to what we will one day call 2.0
[17:51] <tdonohue> but, I also wonder if carynn's right that a shim for 1.7 may be easier -- but, I'll leave it up to the GSoC project team to decide
[17:51] <mdiggory> either that or we throw the numbering convention int he trash ;-)
[17:52] <carynn> numbers are highly over-rated :-/
[17:52] <mdiggory> I think we need to consider what is "storage" and what is "business" in the design here...
[17:52] * bojans (~Bojmen@62.68.103.170) has joined #duraspace
[17:53] <mdiggory> bojans: hello, welcome
[17:53] <bojans> hi
[17:53] <mdiggory> you might want to catchup in the logs breifly....
[17:53] <mdiggory> http://duraspace.org/irclogs/index.php?date=2010-06-02
[17:53] <bojans> ok I will get through the logs, thanks
[17:53] <mdiggory> I did make some comments about rest
[17:54] <mdiggory> stepping back to the topic of "dspace-storage"
[17:55] <mdiggory> We are currently seeing (1) StorageProviders providing "persistence" and the StorageService frontend providing some buisness.
[17:56] <mdiggory> thinking back to RichardRodgers "pluggable assetstore" implementation... is another way to think about "storage"
[17:56] <mdiggory> in that case we are just talking about "streams"
[17:57] <mdiggory> and the implementation of the dspace-fedora (if I understand correctly) used this to its advantage?
[17:57] <mdiggory> thats actually a question for andriusbl
[17:58] <andriusbl> well
[17:58] <andriusbl> it's an implementation of DSpace2 interfaces
[17:58] <andriusbl> it's a littbe bit different
[17:58] <andriusbl> little
[17:59] <mdiggory> yes, ok, maybe we are not going back far enough...
[18:00] <andriusbl> the first prototype project (GSOC2008) used this
[18:00] <andriusbl> ok, so is it suggested i should try making it the second way (DSpaceObject "cover over" by dspace-storage)?
[18:01] <mdiggory> I think we need to weigh the benefits of doing so and what we want to gain from using the StorageServices if we do it that way
[18:02] <mdiggory> I'm not sure the community knows the best direction, but is leaning towards the shim approach conservatively.
[18:03] <andriusbl> so what about DSpaceObject? is it desirable to be in the code, or it should dissapear in time?
[18:04] <mdiggory> It should be abstracted away over time.
[18:04] <mdiggory> but that just my opinion...
[18:04] <mdiggory> The interesting thing is that the shim approach opens up opportunities for you to leverage bojans work from last year... and for bojans and you to possibly collaborate on how the EntityBroker would be layered onto that shim.
[18:04] <tdonohue> yes -- i'd agree, it's fine if DSpaceObject goes away over time. I just was pointing out that may be hard to do by 1.7 (as so much depends on it being there)
[18:05] <mdiggory> If done correctly dspace-rest <--> EntityBroker <--> dspace-storage <--> LegacyDSpace
[18:05] <mdiggory> and also
[18:05] <carynn> i agree - DSpaceObject should disappear.
[18:05] <mdiggory> dspace-rest <--> EntityBroker <--> dspace-storage <--> Fedora
[18:05] <mdiggory> and also
[18:05] <mdiggory> dspace-rest <--> EntityBroker <--> dspace-storage <--> JCR/Jackrabbit
[18:06] <andriusbl> yes, it's probably impossible to remove all 163 references in one summer, but maybe its possible to remove some of them...?
[18:06] <mdiggory> andriusbl: it may or may not be necessary to be concerned with their replacement
[18:06] <tdonohue> yea, I think that'd be possible -- oh, and it's actually 661 total references (in 163 different files)
[18:06] <andriusbl> :)
[18:08] <mdiggory> This direction suggests that something like DSpace 1.8 might be a replacement stage.
[18:08] <carynn> mdiggory: +1
[18:08] <tdonohue> mdiggory -- yea, I think that's more reasonable
[18:08] <mdiggory> and that 1.7 would be an integration stage, especially for something like dspace-rest
[18:09] <tdonohue> exactly -- 1.7 is integration, 1.8 is replacement -- it'd be too hard to jump straight to full-fledged replacement :)
[18:09] <mdiggory> and that dspace-rest, dspace-storage and the semantic store projects could almost be worked on in parallel to the trunk
[18:10] <mdiggory> as a collaborative effort to prove "dspace-storage" concepts against "dspace-rest" intitially.
[18:12] <tdonohue> that all sounds reasonable to me
[18:13] <mdiggory> so, IMO, this is where the "collaboration effect" come into play this year, for the rest, storage and semantic components to come together this year successfully. We are going to need bojans, andriusbl and yigang coordinating and working on these issues together. How tractable does this seem. andriusbl and bojans do you feel it is possible on your side?
[18:14] <mdiggory> note... you can oppose this... its allowed ;-)
[18:14] <bojans> sounds reasonable for me too, but I think it will require additional effort to be invested
[18:15] <andriusbl> we'll try our best ;)
[18:15] <bojans> :)
[18:16] <tdonohue> as mark notes -- we encourage everyone to speak their mind freely -- don't be afraid to disagree or tell us if something just is "not working" -- none of us will be offended, and you won't get docked on your final grade or anything
[18:17] <bojans> for the coordination part I am a little bit skeptic
[18:17] <mdiggory> absolutely, maybe it will be best to leave a window of discussion until the next meeting to formalize opinions and positions.
[18:18] <bojans> for me some of the parts of planning are not completely clear
[18:18] <bojans> I mean there is still discussion in which discussion some things should go
[18:18] <mdiggory> bojans: I was just going to say.... So what I may propose is that we need to find a time that all three of you can be present in IRC on a regular basis to engage on the topic and work towards a design/implementation roadmap/plan
[18:18] <mdiggory> and that is to be expected
[18:19] <mdiggory> All the projects went into this year with significant "lack of specification".
[18:20] <mdiggory> And they really did so because we are at a point this year that is pivotal
[18:20] <mdiggory> there is a great deal of uncertainty about the appropriate path forward for DSpace.
[18:20] <bojans> mdiggory: agree, and this time I would like to us to find a efficient way to have right specification to be done
[18:22] <mdiggory> In talking about that we need to know what the components of a "right specification" should be
[18:22] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithg)
[18:23] <mdiggory> (I'm looking to see others feedback here)
[18:23] <mdiggory> wink wink nod nod, ya know what I mean ya know what I mean....
[18:23] <tdonohue> mdiggory -- I think your idea of scheduling some more meetings to work things out makes sense -- that will help specify what the goals of each project need to be (and where the overlaps are)
[18:24] <tdonohue> I think it'd be good to get a next meeting scheduled soon to try and dig into details more -- and help clarify the questions that still loom
[18:24] <carynn> for the spec, we should also include language about how the code should be submitted, yes?
[18:24] <bojans> I whink andriusbl and me are in the same time zone, so regarding irc meetings it should not be a problem to coordinate actively
[18:25] <mdiggory> yes, that is a benefit
[18:25] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[18:25] * tdonohue i unfortunately need to leave shortly...
[18:25] <mdiggory> tdonohue: I agree on the getting a schedule ironed out before the end of this meeting.
[18:26] <mdiggory> carynn: I think were mtrying to be more on the lines of "specification" for design more than code
[18:26] <carynn> got it
[18:27] <mdiggory> Iw as trying to get some feed in from the community on what the specifications for these projects should include.
[18:27] <mdiggory> bojans has been doing a good deal of REST api definitions on the WIKI and that is great, but he's not getting much feedback on them
[18:27] * pvillega sorry but I got to leave. See you next meeting!
[18:27] * pvillega (~pvillega@89.100.155.181) Quit (Remote host closed the connection)
[18:28] <carynn> yah, i actually just took a look at bojans page - that is a great resource!
[18:28] <tdonohue> I'll try and dig more into bojans page (saw the recent edits) and see if I can provide any feedback
[18:28] <carynn> me2
[18:29] <bojans> ok generally for the rest page
[18:29] <mdiggory> and thats at the "surface" as possible requirements for the restful interface... but once you get under the hood... thats where we are currently lacking requirements for specification
[18:30] <tdonohue> I'd also encourage you to post a message to dspace-devel about the projects, etc. The Unit Testing project has been advertising updates there, along with next meetings (as a way to try and invite more community members) -- stuartlewis, the mentor of that project just started doing that, and it seems to be working well so far
[18:30] <mdiggory> I assume those will be"technical specifications" which outline what functionality should be in what modules and thus which projects
[18:30] <bojans> yes from my view the requirements with regards to relationships and between different components are not clear enough, for example dspace-rest -> (EB) -> new_storage
[18:31] <tdonohue> I unfortunately have to head out -- I'll catch up on the final discussions later. Welcome again to andriusbl, bojans and pvillega -- we are glad to have you all helping out this summer!
[18:31] <mdiggory> yes, that does seem to be working for that single project. I will need some help to get it working for three
[18:32] <mdiggory> So I will ping aaron on that topic as well.
[18:32] <bojans> so in regards to some comments I was thinking to change the concept of endopints to some similarly looking to ontology, e.g. to concentrate more on relationships which could be mapped to ontology concepts
[18:32] <tdonohue> mdiggory -- just have each student/mentor write up a message to advertise each one -- then send occasional updates when feedback is needed, and advertise upcoming meetings
[18:33] <carynn> it might also be helpful to have a page that lays out how these separate projects should be integrated... (kind of a separate spec)
[18:33] <tdonohue> +1 carynn -- documenting the integration points early on could be nice...
[18:33] <mdiggory> carynn: yes and I had started a "scratch-page" along those ines
[18:33] <tdonohue> ok...gotta go
[18:33] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:34] <mdiggory> its currently broken...
[18:34] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/GSoC+Collaboration+Scratchpad
[18:35] <mdiggory> bojans: so there would be "relation" endpoints allowing you to access, list, update, add, delete relations?
[18:36] <mdiggory> this is similar to what you started to comment on over email.
[18:36] <bojans> I have meant on description of relations of objects, e.g. isPartOf
[18:36] <carynn> yep, this would be useful! so, if i'm seeing things correctly, all the specs are available for mentors/developers/committers to comment on (except for Yigang's spec).
[18:36] <bojans> yes that is similar I got this idea from your comments
[18:37] <carynn> would be good to see a message on the listserv requesting review/comments, and include any specific questions (like the relation issue)
[18:38] <mdiggory> good point carynn I believe there is some thread in the lsitserv atm. But just to reinforce, if we are emailing about project plans/questions and its not a private topic, it should be going on in the lsitserv
[18:39] <carynn> bojans: do you have a set of relations that you are thinking about supporting?
[18:40] <mdiggory> I corrected the page and added a OmniGraffle diagram i was working on prior to the meeting....
[18:40] <mdiggory> http://fedora-commons.org/confluence/download/attachments/20808311/Screen%20shot%202010-06-02%20at%2011.54.19%20AM.jpeg
[18:40] <carynn> nice
[18:41] <mdiggory> this is in comparison to my perception of last years rest project in relation to dspace2 rest
[18:41] <mdiggory> http://fedora-commons.org/confluence/download/attachments/20808311/Screen%20shot%202010-06-02%20at%2011.52.59%20AM.jpeg
[18:42] <mdiggory> This is not anything concrete and probably full of misconception so... critique is neccessary
[18:44] <bojans> ok from these diagrams the relation StorageEntityProvider -> StorageEntity seems critical for me
[18:45] <bojans> and probably the relation between StorageService and particular storages
[18:46] <mdiggory> I would hope that the particular storages under the hood would be abstracted away by the StorageService/StorageEntity
[18:46] <mdiggory> So that StorageEntityProvider would be the same no matter the underlying store
[18:47] <mdiggory> But, likewise, we might see that the providers might be more finely typed than what we see here.
[18:48] <mdiggory> Thinking of Container and File resources for instance
[18:48] <mdiggory> that are not represented in StorageEntity atm
[18:49] <mdiggory> Container and File would be StorageEntities and the relations between them would define that as so
[18:49] <mdiggory> Container --> hasPart --> File --> ispartof --> Container
[18:50] <mdiggory> and that is the type of relation we were talking about.
[18:51] <bojans> ok I have better understanding now
[18:51] <mdiggory> But we never arrived to a decision about if those needed to be "concrete" objects int eh java sense
[18:51] <mdiggory> so in the DSpace2 research, we tried to keep all that abstracted away
[18:52] <bojans> you mean on relations as objects?
[18:52] <mdiggory> Container and File...
[18:53] <mdiggory> we do have "relation" as sort of an object....
[18:53] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-storage/trunk/api/src/main/java/org/dspace/services/model/StorageProperty.java
[18:53] <mdiggory> Even int he sense that it can contain "bits of content"
[18:54] <mdiggory> public StorageProperty(String name, InputStream value)
[18:55] <mdiggory> note... at time I wish this were an interface, not a class
[18:56] <mdiggory> We stuck "InputStream" in here and pass around an "Object" that is the value and could be anything... very underspecificed
[18:57] <mdiggory> We extended StorageProperty to also create StorageRelation
[18:57] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-storage/trunk/api/src/main/java/org/dspace/services/model/StorageRelation.java
[18:57] <mdiggory> or a property that connects two different StorageEntities
[18:58] <mdiggory> But it really doesn't do anything more than StorageProperty
[18:59] <carynn> unfortunately, i have to head out... i'll go back over the logs later, and take a look at the pages on the confluence site too...
[18:59] <carynn> welcome bojans and andriusbl!
[18:59] <bojans> thanks carynn
[18:59] <mdiggory> So, I caution that there are some rough areas of the storage-service that could use review and recommendation.
[18:59] <mdiggory> thanks carynn
[18:59] <andriusbl> thanks
[18:59] * carynn (~cneiswen@c726.staff.lib.uci.edu) has left #duraspace
[19:00] <mdiggory> and that this can be an activity of your project if you see value in it.
[19:03] <mdiggory> This is a way that you and andriusbl can collaborate. If in his work to create a shim on DSpaceObjects or your work to place a REST api on top lead to needing to adjust the API, then that is something you should feel free to approach. And, I really think that way of working would really lead to a "real OS community" interaction between your two projects.
[19:05] <mdiggory> Ok, are we out of time... or has everyone nodded off...
[19:06] <mdiggory> So I'll just summarize what need to happen next, and call the meeting adjourned.
[19:07] <mdiggory> 1.) I'll draft an email (and prod AaronZ as well) for announcing our project activities and soliciting feedback.
[19:08] <mdiggory> 2.) We'll plan to need to provide updates weekly on what is being discussed
[19:09] <mdiggory> 3.) I'll review the times and try to get together a meeting time that overlaps with bojans andriusbl and yigang so that you have an opportunity to all be present at once for discussions
[19:11] <mdiggory> 4.) bojans and andriusbl wrk to add more detail to your proposals and the collaboration scratchpad so we can discuss technical specifications next meeting.
[19:11] <bojans> ok
[19:11] <mdiggory> what IDE's are you guys using
[19:11] <mdiggory> ?
[19:11] <andriusbl> Eclipse
[19:12] <bojans> I am using netbeans
[19:13] <mdiggory> great so we are all using totally different IDE
[19:13] <mdiggory> I'm on IDEA
[19:13] <bojans> :)
[19:13] <andriusbl> :)
[19:14] <mdiggory> thus we will get great platform coverage ;-)
[19:15] <mdiggory> I was going to recommend unofficially if you could try checking out the dspace-storage, services, rest and database projects and test if they build and run ok...
[19:15] <bojans> we will be able to exploit many different possibilities :)
[19:16] <andriusbl> run tests?
[19:16] <mdiggory> I assume the process will be a bit different on each.
[19:16] <mdiggory> yes basically if "mvn test" works on those, we are good to go...
[19:17] <andriusbl> do i correctly understand, some dspace modules does use nested maven modules?
[19:19] <mdiggory> yes, actually a number od
[19:19] <mdiggory> od = do
[19:19] <andriusbl> and new versions of maven deprecates them :)?
[19:19] <mdiggory> I reached a point where it became exceedingly difficult to work without them.
[19:20] <mdiggory> from a "build" standpoint
[19:20] <mdiggory> not technologically, but culturally, the community has a tendancy to want to group
[19:21] <mdiggory> this said, I've tried to tread lightly on the use of features like dependency in multimodule builds
[19:21] <andriusbl> eclipse does have working sets
[19:21] <mdiggory> you should be able to stil lcheckout individual modules and compile them in eclipse
[19:22] <mdiggory> if you cannot, then we need to do a little adjustment to support it
[19:22] <andriusbl> i think everythingk will be ok
[19:22] <mdiggory> Here are how I attempt to reduce multi-module parent inter-dependencies...
[19:23] <mdiggory> no use of dependencManagement
[19:23] <mdiggory> no dependencies defined in parents
[19:23] <mdiggory> avoid profiles in parents
[19:23] <mdiggory> avoid creating ancestry chains
[19:24] <mdiggory> so generally I am trying to just use one parent....
[19:24] <mdiggory> ... . <parent>
[19:24] <mdiggory> <artifactId>dspace-pom</artifactId>
[19:24] <mdiggory> <groupId>org.dspace</groupId>
[19:24] <mdiggory> <version>3</version>
[19:24] <mdiggory> </parent>
[19:25] <mdiggory> this defines... very little other than the java build environment and some locations of repositories/resources
[19:25] <mdiggory> and it is always a published centrally available pom.
[19:25] <mdiggory> http://repo2.maven.org/maven2/org/dspace/dspace-pom/
[19:27] <mdiggory> Ideally, someday, allthese maven projects will evolve into OSGi bundles.
[19:31] <andriusbl> ok, i see
[19:51] * andriusbl away for sleep, till next meeting!
[19:52] <bojans> I need to go too, so until next time, cheers!
[19:52] * bojans (~Bojmen@62.68.103.170) Quit (Remote host closed the connection)
[20:11] * achelous (~tom@216.160.210.151) has joined #duraspace
[20:54] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Quit: mdiggory)
[21:08] * achelous (~tom@216.160.210.151) Quit (Ping timeout: 245 seconds)
[21:08] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[21:09] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:18] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[21:51] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) Quit (Ping timeout: 265 seconds)
[22:25] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (*.net *.split)
[22:25] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (*.net *.split)
[22:28] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[22:28] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[23:16] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 240 seconds)
[23:19] * stuartlewis (~stuartlew@130.216.90.94) has joined #duraspace
[23:19] * stuartlewis (~stuartlew@130.216.90.94) Quit (Remote host closed the connection)
[23:20] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[23:29] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Read error: Connection reset by peer)
[23:30] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
