Timestamps are in GMT/BST.
[6:46] -card.freenode.net- *** Looking up your hostname...
[6:46] -card.freenode.net- *** Checking Ident
[6:46] -card.freenode.net- *** Found your hostname
[6:46] -card.freenode.net- *** No Ident response
[6:46] [frigg VERSION]
[6:46] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:46] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:46] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[6:46] -card.freenode.net- [freenode-info] help freenode weed out clonebots -- please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
[6:59] * achelous (~tom@174-126-228-87.cpe.cableone.net) Quit (Ping timeout: 276 seconds)
[12:17] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:28] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:29] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[13:42] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 265 seconds)
[13:50] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[13:54] * Tonny_DK (~thl@130.226.36.117) Quit (Remote host closed the connection)
[14:56] * achelous (~tom@216.160.210.151) has joined #duraspace
[16:13] * achelous (~tom@216.160.210.151) Quit (Ping timeout: 255 seconds)
[16:15] * achelous (~tom@216.160.210.8) has joined #duraspace
[16:37] * achelous (~tom@216.160.210.8) Quit (Ping timeout: 252 seconds)
[17:02] * achelous (~tom@216.160.210.151) has joined #duraspace
[19:02] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[19:35] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[19:53] <mhwood> I'm going to be late -- got to meet the tech rep for repair of a SAN box.
[19:58] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[20:00] <tdonohue> Hi all -- about to start the DSpace Developers meeting here. Today's general agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-09-01
[20:01] * richardrodgers (~richardro@dhcp-18-111-12-48.dyn.mit.edu) has joined #duraspace
[20:01] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[20:01] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) has joined #duraspace
[20:01] <tdonohue> Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-09-01
[20:02] <tdonohue> wanted to start off with some more JIRA catchup first... I know a few folks will be here late (mhwood and kshepherd, likely), so that will give us a chance to catch them later
[20:02] <mdiggory> Hello
[20:02] <tdonohue> hi mdiggory
[20:03] <tdonohue> Here's a list of recent JIRA issues -- we'll start with DS-588 http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-18w&assigneeSelect=&sorter/field=created&sorter/order=ASC
[20:03] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[20:03] <tdonohue> DS-588: Patch for SFX (OpenURL resolver) http://jira.dspace.org/jira/browse/DS-588
[20:04] <richardrodgers> Anyone tested it?
[20:04] <tdonohue> not had a chance to really look at this one, to be honest --- anyone?
[20:05] * joseblanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[20:05] <tdonohue> (I wonder if one of our NZ devels have looked at it -- since the example site is http://researchspace.auckland.ac.nz/handle/2292/5763)
[20:06] <tdonohue> No response -- I'll add a comment to DS-588 and ping Stuart & Kim about it (to see if they are aware or have reviewed)
[20:06] <tdonohue> next one: DS-594: DCDate parsing thread synchronization issue http://jira.dspace.org/jira/browse/DS-594
[20:07] <tdonohue> Robin has already claimed this one -- but it is unscheduled for release
[20:07] <mdiggory> This is our one broken unit test right?
[20:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Read error: Operation timed out)
[20:08] <tdonohue> DCDate has many problems, yes -- robin has been taking a lead on them, so we could link DS-594 up with the other DCDate JIRA issues
[20:09] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[20:09] <tdonohue> DS-594 -- I'll ping Robin, and link this to the other DCDate issues in JIRA
[20:10] <tdonohue> DS-598 : SWORD will only accept deposits on the URL configured in dspace.cfg http://jira.dspace.org/jira/browse/DS-598
[20:11] <tdonohue> Any volunteer to review Graham's code for DS-598? Or should I assign to our local SWORD expert (stuart) and hope he has time :)
[20:11] <richardrodgers> Seems OK - we have a new 1.7 SWORD things we want in - so assign to me
[20:11] <richardrodgers> new -> few
[20:11] <tdonohue> ok, DS-598: assign to richardrodgers for 1.7
[20:12] <tdonohue> DS-599 : SOLR statistics file download displays all files and not only those in the Bundle Original http://jira.dspace.org/jira/browse/DS-599
[20:12] <mdiggory> I suspect this should go our way
[20:12] <mdiggory> assign me for now...
[20:12] <tdonohue> I've verified that DS-599 happens on demo.dspace.org
[20:12] <PeterDietz> For us, it is annoying to see counts for items in the thumbnails bundle, i don't know if anyone wants this to be configurable
[20:13] <tdonohue> ok, DS-599 : assign to mdiggory
[20:13] <tdonohue> mdiggory, do you want to schedule for 1.7 or what to decide later?
[20:13] <mdiggory> schedule for 1.7
[20:13] <tdonohue> err...wait, not what
[20:13] <tdonohue> DS-599: assign to mdiggory, schedule for 1.7
[20:14] <tdonohue> DS-600: Add more information about File Downloads to Statistics Reports http://jira.dspace.org/jira/browse/DS-600
[20:14] <tdonohue> DS-600 is a feature request from Claudia -- though, based on mhwoods comments, we may need to rethink
[20:15] <tdonohue> (i.e. I think mhwood brings up a good point as to what we are really going for in these stats)
[20:15] <mdiggory> schedule for 1.7 and give to me
[20:15] <tdonohue> ok, DS-600: assign to mdiggory, schedule for 1.7 -- more discussion should happen on that issue as needed
[20:16] <tdonohue> DS-601 : Enable styling collection "strength" http://jira.dspace.org/jira/browse/DS-601
[20:17] <tdonohue> DS-601 seems like a very minor patch, but potentially useful for CSS styling....thoughts?
[20:17] <mdiggory> +0
[20:17] <PeterDietz> DS-601 seems harmless, theres no default xmlui theme though
[20:18] <mdiggory> DIM-Handler is default enough
[20:18] <tdonohue> yea, i think the default theme is unnecessary, as it relies on DIM-handler
[20:18] <tdonohue> volunteers for DS-601?
[20:19] <tdonohue> I'll take it then -- seems minor enough
[20:19] <tdonohue> DS-601: Assign to tdonohue, schedule for 1.7
[20:19] <tdonohue> Skipping over DS-602 as it is a self claimed "marker ticket" : Marker ticket for developing a Sword client for DSpace. (http://jira.dspace.org/jira/browse/DS-602) -- nothing to review yet
[20:20] <tdonohue> DS-603 : Having a most used item list similar to the recent submissions http://jira.dspace.org/jira/browse/DS-603
[20:21] <PeterDietz> I'm +1 on feature, needs someone to develop though
[20:21] <richardrodgers> I think this needs a bit more definition - as mwood comment indicates
[20:21] <mdiggory> most used?
[20:21] <mdiggory> most downloaded?
[20:22] <mdiggory> thats just Site wide statistics
[20:22] <tdonohue> I think this likely could mean "most downloaded" -- we had that in our old stats at Illinois
[20:22] <tdonohue> yea -- that's sitewide stats, essentially
[20:22] <mdiggory> note, sitewide statistics can be exposed, they just were not an example that we included
[20:22] <tdonohue> well -- it's probably a matter of exposing them then, so that people know they are there
[20:23] <mdiggory> remember, 1.6 statistics was to get it out the door, not to be full featured.... please attend Ben talk about stats to find out more
[20:23] <tdonohue> should we ask for more details from claudia?
[20:23] <PeterDietz> What definition would work best? Use = Page Visit + Download
[20:24] <PeterDietz> Or leave open ended/configurable, Use = Download
[20:24] <mdiggory> see http://circle.ubc.ca/
[20:24] <mdiggory> "Top Three Items"
[20:24] <tdonohue> I think "most downloaded" is actually what more faculty would be interested in, to be honest -- most people don't care much if you visit their metadata splash page
[20:24] <mdiggory> just visits
[20:24] <mdiggory> but could be reconfigured to be downloads
[20:25] <tdonohue> DS-603 : Ask for more details from claudia? What does she mean by "use"? Needs a volunteer to implement or look into once we have more details
[20:26] <mdiggory> just assign to me, I'm creating a larger enhancement activity proposal for @mire.
[20:26] <tdonohue> ok, DS-603 -- assign to mdiggory, also ask for more details from Claudia
[20:26] <tdonohue> DS-605 : Blank screen on XMLUI Dspace 1.6.0 http://jira.dspace.org/jira/browse/DS-605
[20:27] <tdonohue> oh, this is that strange, sporadically appearing issue in the XMLUI (I remember this came up on one of the lists a while back) -- anyone had a chance to look at this closer?
[20:27] <tdonohue> it's also gotten 3 votes in JIRA: http://jira.dspace.org/jira/secure/ViewVoters!default.jspa?id=10941
[20:27] <richardrodgers> We call that the 'White Screen of Death' - I think it is very important
[20:28] <mdiggory> did you try stopping use of mod_jk
[20:28] <mdiggory> ?
[20:28] <richardrodgers> don't know mdiggory - Sands is looking at it and is out today...
[20:29] <tdonohue> can you touch base with Sands? see if he's any further on this, or if it's still a confusing, seemingly random issue?
[20:29] <tdonohue> (i.e. it'd be nice if we could figure out a way to replicate this, obviously)
[20:30] <richardrodgers> yes we are working on it & I will report any progress
[20:30] <tdonohue> ok, DS-605 : keep unassigned for now -- richardrodgers will touch base with Sands on status, schedule for 1.7 (as this is an annoying issue)
[20:30] <tdonohue> shall we stop there for today?
[20:31] <PeterDietz> maybe, since we ran over last time
[20:31] <mdiggory> ok
[20:31] <tdonohue> ok -- so, we have 1.7 updates next (i'd like to keep it quick and see if we can talk about async releases a bit, since mdiggory is with us today!)
[20:32] <tdonohue> One update from me -- we have the Docs on the Wiki now: https://wiki.duraspace.org/display/DSDOC/DSpace+Documentation
[20:32] <richardrodgers> I have created dspace-curation branch - will follow with some doco on wiki
[20:32] <mdiggory> only comment... have the doc files been dropped from svn?
[20:33] <tdonohue> mdiggory -- not yet. The plan is that as of 1.7, the primary docs will be in the Wiki. Jeff is still working on cleanup though, so we don't want to remove other versions from SVN quite yet
[20:33] <PeterDietz> This essentially replaces the "other" dspace documentation pages?
[20:33] <mdiggory> ok, maybe a jira task scheduled to do this prior to release then..
[20:34] <tdonohue> mdiggory -- good point! i'll take care of that and assign to Jeff
[20:34] <tdonohue> PeterDietz -- this Wiki area replaces the official docs (currently in DocBook). It also allows us to move docs from our DSpace wiki over to the Official documentation easier.
[20:34] <mdiggory> But otherwise, it looks very good
[20:35] <PeterDietz> OK, Some words of encouragement, DSpace 1.7 will be the best release ever, (since it incorporates the work of previous releases as well)
[20:35] <tdonohue> But, this Docs Wiki area is *only editable* by Committers & trusted Doc Gardeners -- general people can only *view* and not edit
[20:36] <tdonohue> haha...thanks for the words of encouragement, PeterDietz :)
[20:36] <tdonohue> any other 1.7 updates/thoughts or should we discuss Async for a while (and come to a plan around moving forward there)?
[20:36] <PeterDietz> I would say I've seen progress on assigned tasks in the "big whats new in 1.7", especially the green checkmarks, so lets keep working on assigned things, and lets take a look at everything thats been delayed as -1, for post 1.5.2 and -1 post 1.6
[20:36] <PeterDietz> http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&fixfor=10031&status=1&status=3&status=4&status=10000&assigneeSelect=unassigned&sorter/field=created&sorter/order=ASC
[20:37] <PeterDietz> Have we looked at DS-135 already? http://jira.dspace.org/jira/browse/DS-135
[20:38] <richardrodgers> looks like it needs a volunteer
[20:38] <tdonohue> DS-135 was discussed a bit last week, in relation to another tombstone issue (though I now realized I forgot to link them as related)
[20:38] <tdonohue> it does need a volunteer
[20:39] <richardrodgers> (cough cough - new committers)
[20:40] <mdiggory> http://bit.ly/1cnJ6j
[20:40] <richardrodgers> ha ha mdiggory
[20:40] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Quit: keithgilbertson)
[20:40] <tdonohue> well, it is scheduled for 1.7 -- we can continue to pester for volunteers going forward (as it will continue to be on that 1.7 list)
[20:40] <PeterDietz> ohh right, these are the nobody's touched list, I'll continue
[20:41] <PeterDietz> http://jira.dspace.org/jira/browse/DS-192 bitstreams returned in an order
[20:41] <PeterDietz> I would like order of bitstreams to be ordered, as a project I'm working on requires them to be properly ordered
[20:42] <PeterDietz> So I will grab this, unless there's any words of advice about this being particularly tricky.
[20:42] <tdonohue> PeterDietz -- are you wanting to go through all of these now? It seems like we already scheduled all of these for 1.7 -- and we only have 4 of us active in this chat (you, mdiggory, richardrodgers and myself -- though we have others in here listening)
[20:42] <richardrodgers> I'm fine with this - but sequence ID should not be basis of it
[20:42] <mdiggory> saw that coming richardrodgers
[20:42] <PeterDietz> I'm thinking to add another field to database, an order
[20:43] * mdiggory worries about more fields in db
[20:43] <kshepherd> hi all
[20:43] <PeterDietz> seuqence is unsafe to touch
[20:43] <PeterDietz> hi kshepherd
[20:44] <PeterDietz> ok, I'll curb the review old stuff, but if you have free effort, and are interested, feel free to take one
[20:44] <PeterDietz> next, asynch
[20:44] <mdiggory> thinking about versioning... right now sequence ids are the only identifier for a bitstream that gets exposed....
[20:44] <tdonohue> I should say, I think it's important to go back and review this (and we can do a few each week if you wish, PeterDietz) -- just don't think we can do all of them today
[20:45] <mdiggory> suppose an order field is tolerable
[20:45] <tdonohue> Ok, on to Async -- I'm essentially wanting to form a "game plan" here -- we've been talking for months and it's time to do something (if we want it ready for 1.7)
[20:46] <mdiggory> I began to throw ideas out there last week... now I can focus a little more on them
[20:46] <mdiggory> initial idea I had was to start by altering the release process.
[20:46] <richardrodgers> I'd say let's examine the requirements we have for a specific contemplated releasable thing
[20:46] <tdonohue> sure, I also documented much of what you've said before, mdiggory -- see agenda built point: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-09-01
[20:47] <mdiggory> yes, well done
[20:47] <tdonohue> richardrodgers -- sure, sounds like a good way to take a step back first...what are the requirements here?
[20:47] <mdiggory> the alteration of the release process would do (1) assign separate release numbers to the dspace-api, dspace-xmlui, etc
[20:47] <PeterDietz> What is needed to release dspace. dspace, dspace-api, dspace-jspui, dspace-xmlui. The "extras" could be oai, sword, lni, rest, discovery ?
[20:47] <mdiggory> and (2) run releases of those separately into the existing dspace/tags dspace/branches
[20:48] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[20:48] <mdiggory> I did see the proposal by sands to do some work on the Maven release process, and this might overlap with that
[20:49] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[20:50] <kshepherd> (just using the brief silence to note that i'd like to comment on DS-588 [the sfx patch] later on when the agenda is done)
[20:50] <mdiggory> Questions that emerge in that process are... what happens with dspace/trunk/pom.xml
[20:50] <tdonohue> mdiggory -- those aren't really requirements/goals here? should we tease those out first, before we did into Maven being the appropriate solution?
[20:50] <mdiggory> and the dependencyManagement thats going on in there
[20:51] <richardrodgers> I'd categorize the add-ons as: standalone, extension of another module, needs config data, needs web.xml changes, etc
[20:51] <mdiggory> IMO, one cannot differentiate. async release is tied to maven inexerably
[20:52] <mdiggory> ok ok
[20:52] <mdiggory> Goal 1: to be able to depend on dspace-api independent of official release distro
[20:53] <richardrodgers> Do we want compile-time integration, assembly-time, deploy-time, etc?
[20:53] <mdiggory> So that dspace-api-1.0.0 <--- addon-1.0.1 <--- dspace-release-1.7.0
[20:54] <tdonohue> makes sense to me...
[20:54] <mdiggory> we want all of them
[20:54] <mdiggory> or, at least I can do all of them at once in IDEA
[20:55] <mdiggory> depending on how one sets up ones project
[20:55] <richardrodgers> yes, but that might not be our target audience....
[20:56] <mdiggory> ok, to simplify ... "deploy time" is target audience
[20:56] <mdiggory> though deploy/assembly are not very different to me
[20:56] <mdiggory> and ant is a bandaid atm
[20:57] <richardrodgers> so we have a configured, running instance, and we want to add new modules with or without a fresh install?
[20:57] <tdonohue> Goal 2: needs to avoid extra complexity -- must simplify install/upgrades and NOT make them more difficult than they already are. (does that get to the target audience point?)
[20:57] <mdiggory> realistically, thats going to be a stretch
[20:57] <mdiggory> referring to richardrodgers
[20:58] <mdiggory> not freshinstall... just ant update
[20:58] <mdiggory> or more specifically we would need mvn clean package; ant update;
[20:59] <mdiggory> baby steps... we eneed to break up the release process, then we get to talk about assembly and frameworks/platforms/deployment opportunities that will emerge
[21:00] <richardrodgers> +1 baby steps, that's why I'm trying to bound the problem....
[21:00] <kshepherd> also +1 to reducing complexity
[21:00] <mdiggory> we are in agreement
[21:00] <tdonohue> mdiggory -- my point is that the community will "revolt" if we "baby step" this too much and release something that makes installs/upgrades more complex (for even a short period)
[21:01] <mdiggory> tdonohue: true, I was trying not to "rock" the community too much by suggesting...
[21:01] <mdiggory> 1.) not moving the code out of trunk
[21:01] <mdiggory> 2.) just changing maven version numbering strategy
[21:02] <mdiggory> 3.) releasing modules into same location as... http://scm.dspace.org/svn/repo/dspace/tags/
[21:02] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[21:02] <mdiggory> this would mean there would be....
[21:02] <mdiggory> http://scm.dspace.org/svn/repo/dspace/tags/dspace-api-1.x.x
[21:02] <mdiggory> http://scm.dspace.org/svn/repo/dspace/tags/dspace-xmlui-1.x.x
[21:02] <mdiggory> etc
[21:03] <mdiggory> and separate deployments into maven repository....
[21:03] <richardrodgers> why not just versioned maven artifacts?
[21:03] <richardrodgers> in a release repo?
[21:03] <mdiggory> (2) results in exactly that richardrodgers
[21:04] <richardrodgers> yes but all the directories are noisy - isn't that what tags are for?
[21:05] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[21:05] <mdiggory> clarify
[21:05] <tdonohue> which directories are noisy?
[21:05] <richardrodgers> ok mdiggory - sorry that's all you meant
[21:06] <tdonohue> This sounds relatively reasonable to me ...Do we have a volunteer to start to prototype this out a bit? Is this something we could prototype out before jumping in head first? :)
[21:06] <richardrodgers> Standard maven release tagging at the 'dspace-api' unit granularity
[21:06] <mdiggory> correct
[21:07] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[21:07] <mdiggory> I can prototype in sandbox initially
[21:07] <tdonohue> mdiggory -- I think that'd be nice to do -- it might help us all get more on the same page
[21:08] <mdiggory> but, we still should talk about maven plugins as a means to orchestrate adding addon modules to a dspace distro.
[21:08] <richardrodgers> Unfortunately, I've got to run now - thanks all
[21:09] <tdonohue> bye richardrodgers
[21:09] <kshepherd> cheers richardrodgers
[21:09] * richardrodgers (~richardro@dhcp-18-111-12-48.dyn.mit.edu) Quit (Quit: richardrodgers)
[21:09] <mdiggory> thanks
[21:09] <tdonohue> (all feel free to leave if you need to, though I'm going to stick around here for a bit and talk this through more with mdiggory)
[21:09] <tdonohue> mdiggory, do you have time to continue this for a bit?
[21:10] <mdiggory> some...
[21:10] <tdonohue> if you don't that's fine -- not trying to steal you away, just want to talk more about it while you are here (as I know you have a lot going on these days)
[21:11] <kshepherd> can i just quickly jump in re: DS-588 (sfx) and say we've tested it, it's working.. since we work with yin yin (the author) it would be nice to get some review from people outside Auckland University, but otherwise i'm happy to take responsibility for it and commit it myself
[21:11] <kshepherd> (might be easier to test if i just shove it in trunk, too)
[21:13] <tdonohue> kshepherd -- I'll admit, I've never really used the SFX stuff -- as long as you all feel it is stable and not too Auckland specific, I'm happy -- you could always ask for comments for a few days before you just commit it (by posting a comment to that JIRA issue yourself)
[21:13] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) Quit (Quit: Page closed)
[21:14] <kshepherd> right-o, will do
[21:15] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Ping timeout: 276 seconds)
[21:20] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[21:20] <mdiggory> The ultimate challenge is that we need developers to ramp up on these technologies (Velocity, Maven plugins, etc)
[21:21] <mdiggory> where "developers" means us, not endusers
[21:21] <mdiggory> or more specifically, "
[21:22] <mdiggory> those of us that maintain the build/deployment system for dspace
[21:22] <mdiggory> http://bit.ly/1cnJ6j
[21:41] <kshepherd> http://blogs.targetx.com/snhu/ChrisDupuy/Tumbleweed.jpg
[21:48] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Quit: keithgilbertson)
[21:51] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[21:51] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Client Quit)
[21:53] <tdonohue> mdiggory -- sorry, I missed that you came back online -- when you disappeared, I thought you had to go :)
[21:54] <tdonohue> I've been ramping up more on Maven Archetypes/Plugins recently (or at least digging deeper) -- and I agree 100% that we need us (committers) to be more up-to-speed on all of this
[21:56] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Ping timeout: 252 seconds)
[21:58] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[22:04] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[22:20] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[22:25] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[23:04] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[23:22] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[23:37] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[23:51] * achelous (~tom@216.160.210.151) Quit (Ping timeout: 240 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
