Timestamps are in GMT/BST.
[4:05] -hubbard.freenode.net- *** Looking up your hostname...
[4:05] -hubbard.freenode.net- *** Checking Ident
[4:05] -hubbard.freenode.net- *** Found your hostname
[4:05] -hubbard.freenode.net- *** No Ident response
[4:05] [frigg VERSION]
[4:05] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:05] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:05] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[7:12] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[7:44] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[7:54] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[9:25] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[10:15] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[10:21] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[10:24] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[10:26] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[10:30] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Read error: Connection reset by peer)
[10:39] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:33] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[12:01] * krnl_ (Andrius@83.171.18.74) has joined #duraspace
[13:28] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Quit: scottatm)
[13:54] * robintaylor (~52292565@gateway/web/freenode/x-hnjqrnjtuhbdfitb) has joined #duraspace
[14:29] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[14:30] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[14:38] * robintaylor (~52292565@gateway/web/freenode/x-hnjqrnjtuhbdfitb) Quit (Ping timeout: 252 seconds)
[14:38] * 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:41] * bollini (~chatzilla@87.18.234.106) has joined #duraspace
[14:47] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:58] * robintaylor (~52292565@gateway/web/freenode/x-pxlldkhdqampvofv) has joined #duraspace
[15:10] * robintaylor (~52292565@gateway/web/freenode/x-pxlldkhdqampvofv) Quit (Quit: Page closed)
[15:41] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[15:45] * caryn (~80c8e115@gateway/web/freenode/x-anrbjpxxgycpswle) has joined #duraspace
[15:46] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:48] <bollini> hi all... I have just realized that the meeting start in 15minutes
[15:49] <tdonohue> yep...we'll be starting at the top of the hour
[15:49] <bollini> in Italy we have moved to the solar time last week...
[15:49] <bollini> so I will not able to attend
[15:50] <bollini> just let you know that I haven't stated to work on DS-496
[15:50] <tdonohue> Yea, I know there are a lot of time changes going on worldwide now. Will this time be a problem for you every week, or just this week?
[15:50] <bollini> yes it is an issue
[15:51] <bollini> can you check if we can change the schedule for the next meetings?
[15:51] <tdonohue> ok. that's good to know. I'll bring up the topic of the time of this meeting. We can always change it slightly, if we can find something that works better for most
[15:52] <stuartlewis> It will get hard for us next week too, as our clocks go BACK 1 hour.
[15:52] <stuartlewis> So too late for you, and too early for us! :(
[15:53] <grahamtriggs> I know the water goes down the plughole backwards down there, I didn't realise the clocks went backwards too :)
[15:53] <tdonohue> hmm...that is a problem. well, it doesn't hurt to see if there's a time that works better for most -- but, we may just have to accept the fact that not everyone will be able to attend in person
[15:53] <stuartlewis> It'll be 8am for us - so doable, but not too bad.
[15:54] <bollini> sometimes I can attend too (10pm)
[15:55] * rtaylor (~52292565@gateway/web/freenode/x-ozwyetaqlecqdhax) has joined #duraspace
[15:55] <tdonohue> ok. well, I'll send out a survey to everyone to get a sense of whether or not we should change the current time.
[15:55] <stuartlewis> An hour earlier might work. 7am for us.
[15:55] <stuartlewis> Then we could attend before going to work.
[15:56] * cccharles (~cccharles@131.104.62.47) has joined #duraspace
[15:56] <stuartlewis> Kshepherd will be the main person to worry about as he's a new RC.
[15:56] <mdiggory> Actually, an hour earlier in the US was where it was scheduled before the time change
[15:56] <grahamtriggs> stuartlewis: there is a dress code for these meetings - no turning up in your pyjamas
[15:56] <mdiggory> so my calendar still says our meeting started an hour ago
[15:57] <tdonohue> mdiggory: your calendar is wrong then :) we've always been at 20:00UTC -- it's just a matter of what that now translates to for you
[15:57] <bollini> mmm... I'm sorry I need to leave
[15:57] <bollini> I have found this useful website: http://www.worldtimeserver.com/meeting-planner-times.aspx?&L0=NZ&L1=IT&L2=US-IL&L3=GB&L4=US-NY&Day=8&Mon=4&Y=2010
[15:57] <stuartlewis> grahamtriggs: Smoking jacket and cravat OK?
[15:57] <tdonohue> no problem, bollini. we'll talk to you later then
[15:57] <bollini> but it is not so useful for us... there is not green time for all ;-)
[15:58] <grahamtriggs> stuartlewis: mandatory I would say
[15:58] <mdiggory> eh UTC, those brits always thinking there the center of the world and all...
[15:59] <bollini> ok... just let you know... I haven't start to work on DS-496 but I 'm still volunteer
[15:59] <bollini> bye
[15:59] <grahamtriggs> bloody colonials have to disagree with everything
[15:59] * bollini (~chatzilla@87.18.234.106) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819])
[16:00] <kshepherd> morning *
[16:00] <tdonohue> Ok...looks like it's about that time. We'll go ahead and start up today's DSpace Developers Mtg with several announcements/updates (feel free to comment as I post them)
[16:01] <tdonohue> (1) For those who will be at OR10, we now have our face-to-face meeting scheduled for the afternoon on Monday *before* the Conference. It's likely only going to be a 2-4 hr meeting in mid-to-late afternoon (to avoid conflicts) -- but it will be followed by a pub meetup with the Fedora folks
[16:02] <tdonohue> exact times/place forthcoming (once it is 100% finalized) -- but it's definitely going to be Monday afternoon -- so keep that in mind when setting up flights, etc
[16:03] <tdonohue> (2) Next week's Special Topics meeting will be on upcoming DSpace 1.7 and beyond RoadMap -- announcement via email forthcoming
[16:04] <mdiggory> pub meetup..... I'm there
[16:04] <tdonohue> (3) As you may have seen from prior discussion, this meeting time (20:00UTC) may no longer be the best for all...I'll send out a survey to dspace-devel with some other potential times. But, until then, we'll still meet at 20:00UTC
[16:04] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has joined #duraspace
[16:05] <tdonohue> (4) DSpace Wiki Migration has been slowed down -- unfortunately our wiki contact at MIT (hi Richard) hasn't been able to freeze/dump the old wiki yet. So, as you all have seen, that hasn't happened on Tues (as previously planned)
[16:05] <tdonohue> ok...think that's it for announcements... :)
[16:06] <tdonohue> any questions comments on all that?
[16:06] <grahamtriggs> he should send it over here... I've got no heating until tomorrow... should freeze pretty quickly
[16:06] <tdonohue> grahamtriggs: wrong kind of freezing ;)
[16:07] <mdiggory> I've forgotten what freezing is like....
[16:07] <tdonohue> Ok, well, it sounds like we should continue now with the main discussion topic: GSoC
[16:08] <tdonohue> mdiggory: did you want to lead the GSoC planning discussion?
[16:08] <mdiggory> Yes sure
[16:08] <mdiggory> Ok... looks like we've got a good list of mentors running in the wiki
[16:09] <mdiggory> User:MarkDiggory User:StuartLewis User:Christophe.Dupriez User:Bluyten User:Caryn.n User:wbossons User:Jayan User:ksclarke
[16:09] <tdonohue> Yep. It's here: http://wiki.dspace.org/index.php/Google_Summer_of_Code_2010
[16:09] <mdiggory> odd it thinks those are links.
[16:09] <mdiggory> So I wantt o first start off by making sure everyone who want to participate in GSoC this year is subscribing to the SOCGHOP app as a mentor
[16:10] <mdiggory> following the directions in the page just posted by tdonohue
[16:10] <mdiggory> We need you in there ASAP to start preparing for when student applications come in.
[16:10] <tdonohue> (fyi here's a link to our DuraSpace SOCGHOP page: http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/duraspace)
[16:10] <mdiggory> We are in the student application period now until April 9th
[16:11] * ChristopheDuprie (~5bb333e1@gateway/web/freenode/x-ljopusqahlrblqry) has joined #duraspace
[16:12] <mdiggory> So maybe I'll try to throw out an overview of topic to discuss today
[16:12] <mdiggory> 1.) Project Coordination
[16:12] <mdiggory> 2.) Student Deliverables and Accountability
[16:13] <mdiggory> 3.) Appropriate Projects
[16:13] <mdiggory> 4.) Mentors Responsibilities
[16:13] <mdiggory> Starting with (1)
[16:14] <mdiggory> In previous years Mentors worked fairly autonomously with they students and status of the project was given to the whole group on a periodic basis (every 1 to 2 weeks)
[16:15] <mdiggory> Reporting was done in the listserv and students could document their work where they and the mentor saw fit
[16:16] <stuartlewis> And we're changing that this year? (I hope)
[16:16] <mdiggory> Yes, I beleive we have an interest in changing this process
[16:16] <tdonohue> that's what's up for discussion right now -- I'd also vote to change that process
[16:16] <caryn> would be kind of cool to use google wave... just a thought
[16:17] <mdiggory> I certainly have ideas I've proposed to the group and to tdonohue, but I want to see the group be empowered to determine what would be the best approach here
[16:18] <mdiggory> In past years we recognize that the projects being individual and separate has some limitations
[16:18] <mdiggory> a.) code not getting back to DSpace
[16:18] <stuartlewis> Things like the new demo.dspace.org server might help too - as it allows us to get their code installed and running for poeple to test, rather than anyone interested having to install it themselves.
[16:18] <mdiggory> b.) projects producing code that is not meant to be part of DSpace
[16:18] <caryn> stuartlewis: +1
[16:18] <mdiggory> c.) projects producing code that is conflicting in architecture or design direction
[16:19] * tdonohue ugh...I knew I forgot an announcement: http://demo.dspace.org is ready -- will be announced to all lists later today
[16:19] <mdiggory> tdonohue: does this have any CI associated with it?
[16:20] <grahamtriggs> how feasible is it to update our JIRA instance?
[16:20] <tdonohue> nope...strictly a demo server right now...but, all committers will have access to login via commandline -- so, we can set up other things there as "we wish"
[16:20] <mdiggory> So the points a, b, and c that I make are actually less about the students performance or effort, and much more directed at ourselves as mentors and our coordination.
[16:20] <tdonohue> right now demo.dspace.org is *just* a demo install of Dspace 1.6.0
[16:21] <kshepherd> could we do daily snapshots of trunk and 1.6.x branch?
[16:21] <tdonohue> So, to your points mdiggory, are you suggesting mentor "teams" or co-mentors (which I've heard both mentioned in past discussions)
[16:21] <mdiggory> And likewise our understanding of the direction that we are taking DSpace in as a codebase
[16:21] <kshepherd> (sorry, slight tangent, maybe i'll bring it up later again)
[16:21] * tdonohue will note we should discuss demo.dspace.org after GSOC
[16:21] <stuartlewis> "mentor teams with weekly IRC meetings" +1
[16:22] <mdiggory> tdonohue: yes, one of my recommendations is that we work to create mentor "teams" around the proposed projects
[16:22] <tdonohue> "mentor teams with weekly IRC meeting" +1 as well
[16:22] <mdiggory> Right now we have seen the areas that we as mentors are interested in working, and there is overlap in terms architectural decision making even withint he various subject areas
[16:22] <PeterDietz> would that be in #dspace or in #dspace-gsoc1, #dspace-gsoc2
[16:23] <kshepherd> +1, though i'm not a mentor so perhaps i shouldn't be voting
[16:23] <caryn> +1 - would give the students the best experience as well... more like "community development"
[16:23] <ChristopheDuprie> +1 for mentors team with at least one committer within the team
[16:24] <tdonohue> ChristopheDuprie: good point there...it'd be nice to get at least one committer on each to help bring the code forward after GSoC ends
[16:24] <mdiggory> Much of this depends as well on what we get for students this year.
[16:24] <richardrodgers> guess I'm not as convinced - if mentor time was an issue before, doesn't multiplexing make it worse?
[16:24] <tdonohue> mdiggory: definitely
[16:25] <mdiggory> Originally, in years past we did utilize co-mentors on projects such that there was a primary mentor and backup mentor should the primary become unavailable.
[16:25] <mdiggory> However, this was never trully a "team strategy"
[16:25] <grahamtriggs> I thought mdiggory was driving more at having team(s) across all the projects, not having each one as a silo
[16:26] <mdiggory> And oftentime the communication between the students and mentors was too sparse
[16:26] <mdiggory> grahamtriggs: yes
[16:26] <tdonohue> silo projects -1
[16:26] <tdonohue> so, it's all about trying to foster more "community" development, like caryn mentioned
[16:27] <tdonohue> rather than having a few projects "off on their own" (so to speak)
[16:27] <mdiggory> So as an example: say this year what I have been proposing is that, say we have 6 students and 6 mentors
[16:28] <mdiggory> that while, in the application itself we have those slots filled, we do not work that way organizationally
[16:28] * cbeer_ (~cbeer@146.115.109.46) has joined #duraspace
[16:28] <stuartlewis> 6 students? Wouldn't 3 or 4 be enough? More chance of getting that code well mentored, and into core)
[16:28] <mdiggory> and that we may actually have "more than one" student working an one subject area
[16:29] * cbeer_ (~cbeer@146.115.109.46) has left #duraspace
[16:29] <mdiggory> stuartlewis: I would not limit the number of students we can handle
[16:29] <caryn> i really like this idea. would be good for the mentoring team to develop thought-out benchmarks for the students as well - just so nothing "falls between the cracks"
[16:29] <mdiggory> this is something you've suggested a number of times, and which I disagree with
[16:29] <mdiggory> politely of course
[16:29] <stuartlewis> :)
[16:30] * tdonohue thinks we should set aside the discussion of numbers for now... politely
[16:30] <mdiggory> :-)
[16:30] <mdiggory> I think the number of applicants and the quality of the applicants will determine the number of students we wish to use.
[16:30] <mdiggory> and I'll leave it to that
[16:31] <mdiggory> we will know all this by April 9th
[16:31] <tdonohue> So, in any case, if we work in this team fashion, the one thing we need to be careful about is that each student should still have his/her own project...if we overlap their work too much, it becomes hard to parse out who did what, etc
[16:31] <caryn> tdonohue: +1
[16:31] <ChristopheDuprie> We must not forget students are not knowing much about DSpace internals, aims, etc. We should try to focus them on something rather specific that the mentor/commiter is then able to merge for the longer term
[16:31] <tdonohue> (just a counterpoint to think about here -- still like the team idea though)
[16:31] <mdiggory> This is quite true, but I think we should be grading on things other than "code" during this process
[16:32] <grahamtriggs> tdonohue: maybe, maybe not - I'll direct you back to my question about how feasible it is to upgrade our JIRA instance :)
[16:32] <ChristopheDuprie> I agree that good specs would be as nice than "proof of concept" code we get usually
[16:33] <mdiggory> in working as a team, we are working to create a the proper "interactions" that facilitate a good and healthy F/OSS community
[16:33] <mdiggory> the topic of specs and example code came up last week.
[16:34] <mdiggory> and I think we agreed that code samples of the students past work would be helpful
[16:34] <mdiggory> but not requiring them to create any DSpace centric example code for the application
[16:34] <tdonohue> mdiggory: yea, our application template now asks for a code sample from students
[16:35] <ChristopheDuprie> I mean that a good analysis from a student could be as valuable than code. For instance an analysis of DCMI/DCAP integration in DSpace would be of great value. Sorry I did not read last week log.
[16:35] <mdiggory> So I would like to bring the topic back to what we as mentors/developers what to see as the direction the code projects we are working on goes in this year.
[16:36] <mdiggory> I was hoping we would see a little more detail in the examples that were put out byt he mentors
[16:36] <stuartlewis> Do we all agree a restful API (probably polishing last year's api) is a good project?
[16:36] <mdiggory> We have some solution areas that overlap, but with different proposed implementation strategies
[16:37] <tdonohue> +1 for a REST project
[16:37] <mdiggory> and I think to see success in the projects, we as mentors need to resolve those before we select students
[16:37] <stuartlewis> Can we do that in time?
[16:38] <mdiggory> I am tempted to start throwing project ideas up here as well... but I'm resisting because I think that will lead us off track from what I am attempting to accomplish
[16:38] <mdiggory> stuartlewis: it is a process, not a task/goal
[16:39] <ChristopheDuprie> Go on one at a time!
[16:39] <tdonohue> what about seeing what good applications we get in from students, and seeing which projects we'd most like to see (and perhaps which projects are logically related and can potentially form "teams")
[16:39] <grahamtriggs> Whilst a RESTful interface would be useful, I really think we should have a strategic discussion about how and where DSpace is moving first - creating an API that will either make underlying changes harder, or be problematic to support when changes are made would be a significant issue
[16:40] <mdiggory> grahamtriggs: yes, and I am glad we will have next week to discuss that direction.
[16:40] <tdonohue> before any projects can happen (no matter how bad we want them too), we first need students who are interested :)
[16:40] <stuartlewis> grahamtriggs: Yes. Can that be fitted in during the hiatus between selecting the students, and them starting work in a few months?
[16:40] <mdiggory> tdonohue: right about this....
[16:40] <mdiggory> So to put it out as a proposal
[16:41] <mdiggory> Do we as mentors agree that we want to all work together this year to organize a strategic direction for the student projects as a whole
[16:41] <caryn> +1
[16:41] <stuartlewis> +1
[16:42] <tdonohue> +1
[16:42] <ChristopheDuprie> +1
[16:42] <mdiggory> +1
[16:42] <grahamtriggs> stuartlewis: I think it needs to happen before we select them - although that doesn't mean they can't apply in the meantime.... one perfectly valid outcome of such a discussion is to not do anything in a particular area right now, until other things have happened first
[16:43] <stuartlewis> grahamtriggs: As I said before, can that be done in the time we have to select students? (2 / 3 weeks?)
[16:43] * tdonohue notes that we only have about 15 mins left in our meeting
[16:43] <mdiggory> So during the evaluation process, what I feel needs to happen is that we define a set of criteria we agree on as the basis for evaluating the student proposals, and a process to feedback to the student and get them to adjust the proposal as neccessary to align disparate projects
[16:43] <grahamtriggs> stuartlewis: you said between selecting the student, and them starting work, which I took to mean [including] AFTER they have been selected
[16:44] <mdiggory> and to answer stuartlewis question... Yes, it will require dedicated time to communicate during the evaluation period
[16:44] <mdiggory> grahamtriggs: we have a month of interacting witht he selected students before the GSoC work period begins
[16:44] * stuartlewis apologizes. Gotta run to a another meeting... Will read the transcript later. Bye.
[16:45] <tdonohue> Looking at the time....should we bring the rest of these GSoC ideas/proposals to email? Maybe schedule a separate meeting in the coming weeks -- especially for mentors and those more interested in GSoC?
[16:45] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[16:45] <mdiggory> Yes... I agree... but reiterate... get into the SOCGHOP app and the email lists and google groups so you are aware of the communication going on
[16:46] <mdiggory> I am pushing at this because we were late last year on all these deadlines and suffered because of it.
[16:47] <tdonohue> also, we have two mailing lists this year devoted to GSoC...one for mentors only (no students) 'dspace-gsoc', and one for mentors + students 'dspace-gsoc-student' : http://wiki.dspace.org/index.php/Google_Summer_of_Code_2010#Email_Listservs
[16:48] <mdiggory> tdonohue: we need to go through the dspace-gsoc list and clean up its membership.
[16:48] <tdonohue> agreed
[16:48] <tdonohue> In the time remaining, do we want to jump back to 'demo.dspace.org' questions/thoughts?
[16:48] <mdiggory> likewise, joing the list should be moderated.
[16:49] <mdiggory> tdonohue: per demo, I'd like to see something like Hudson or Bamboo in place on that server with some folks who could manage using it.
[16:50] <kshepherd> tdonohue: it'd be cool if we could get some automated building of daily trunk and 1.6.x snapshots on demo.dspace.org :)
[16:50] <mdiggory> then we can setup integration builds to demo recent work
[16:50] <mdiggory> and with something like a jmeter or httpunit test suite verify functionality is not broken going into trunk
[16:51] <mdiggory> this is EC2 right?
[16:51] <tdonohue> yes...it's on EC2
[16:51] <tdonohue> being paid for by DuraSpace
[16:52] <tdonohue> I should mention that the initial purpose of demo.dspace.org is for *repo managers* to have a place to "play" with the latest version of DSpace before they install it
[16:52] <kshepherd> ah
[16:52] <mdiggory> we need more ;-)
[16:52] <caryn> very good idea!
[16:52] <tdonohue> I think the Hudson or Bamboo ideas are good ones...but, I wonder if we need a different place for that? Or at least a different Tomcat instance on the same server
[16:52] <kshepherd> mm, i think i'll just run my own 1.6.x snapshot somewhere
[16:53] <mdiggory> not a problem thats just configuration
[16:53] <grahamtriggs> Bamboo integrates quite nicely with JIRA
[16:53] <mdiggory> Fedora already has a Bambo running
[16:53] <tdonohue> yes they do have Bamboo...we actually have an old one for DSpace still running at JHU
[16:54] <mdiggory> but not much communication with JHU of late
[16:54] <tdonohue> nope..and it would be good to move elsewhere
[16:54] <tdonohue> I'll admit, I'm not a Hudson or Bamboo expert....but, I'd fully encourage us to get one running for DSpace
[16:55] <tdonohue> info on our old Bamboo at JHU: http://wiki.dspace.org/index.php/ContinuousIntegration
[16:56] <tdonohue> So, in general, it sounds like we'd all like to have Bamboo running somewhere?
[16:57] <mdiggory> Ha, I queried google for "FOSS compute farm Continuous Integration" and the first hit is foaf.qdos.com/delicious/people/ksclarke
[16:57] <mdiggory> and he's not even in here....
[16:57] <tdonohue> nope...he's in #dspace though
[16:58] <mdiggory> I told him...
[16:58] * ksclarke (~kevin@184.39.7.249) has joined #duraspace
[16:59] <mdiggory> ksclarke: we were having an extensive GSoC planning discussion here in the last hour
[16:59] <mdiggory> you should read it up in the logs
[16:59] <tdonohue> ksclarke: not sure if your "ears were ringing"...your name also just came up as we were talking about Continuous Integration for Dspace
[16:59] <ksclarke> ah, will do... I was in a telemeeting the past hour so wouldn't have been able to pay attention anyway
[17:00] <mdiggory> http://duraspace.org/irclogs/index.php?date=2010-03-31
[17:00] <mdiggory> We were just discussing http://demo.dspace.org and the last topic was also about CI
[17:01] <mdiggory> and I was thinking about your working with Hudson quite a bit lately
[17:01] <caryn> sorry, everyone - i've got to go. I'll watch for the email discussion about gsoc and the demo.dspace.org announcement
[17:01] <ChristopheDuprie> 23:00 here! Good night!
[17:01] <tdonohue> Ok, in any case...we're out of time. I'll start discussion in DuraSpace about a Bamboo continuous integration setup (and see how the Fedora folks have theirs working). If anyone else has any other immediate thoughts on CI or other tools they'd like to see to help our development process -- let me know
[17:01] <mdiggory> Cheers
[17:01] * caryn (~80c8e115@gateway/web/freenode/x-anrbjpxxgycpswle) Quit (Quit: Page closed)
[17:01] * ChristopheDuprie (~5bb333e1@gateway/web/freenode/x-ljopusqahlrblqry) Quit (Quit: Page closed)
[17:02] <mdiggory> I guess we should sign-off on the official meeting?
[17:02] <tdonohue> oh, yes. official meeting is closed
[17:02] <tdonohue> but feel free to continue any discussion here or over in #dspace
[17:03] <mdiggory> So both ksclarke and I have een working with Hudson lately, and thats just a war that can be configured accordingly, like Continuum etc
[17:03] <ksclarke> mdiggory :-) yeah, have our dev through hudson is checking every 10 mins for svn updates now, btw
[17:04] <ksclarke> getting ready to duck out for a trip to the pool with my eldest... will read the logs later this eve though
[17:04] <mdiggory> sounds good. think about ideas for CI in the community while your holding your breath
[17:05] <tdonohue> I saw some cool demos of Hudson at Dev8D in London...
[17:05] <tdonohue> (but, I'll admit, I've never used/installed it)
[17:05] <richardrodgers> gotta go bye all
[17:05] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[17:08] * rtaylor (~52292565@gateway/web/freenode/x-ozwyetaqlecqdhax) Quit (Quit: Page closed)
[17:10] * ksclarke (~kevin@184.39.7.249) Quit (Quit: Leaving.)
[17:35] * 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:35] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:56] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[18:06] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:16] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[18:31] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[18:58] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Quit: scottatm)
[18:58] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[19:03] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Ping timeout: 265 seconds)
[19:55] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[19:55] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
[19:55] * mdiggory_ is now known as mdiggory
[20:55] * ksclarke (~kevin@184.39.7.249) has joined #duraspace
[22:08] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[23:56] * ksclarke (~kevin@184.39.7.249) Quit (Quit: Leaving.)
[23:59] * 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.