Timestamps are in GMT/BST.
[2:40] * snail (~yeatesst@130.195.179.88) Quit (Quit: Leaving.)
[2:56] * snail (~yeatesst@130.195.179.88) has joined #duraspace
[6:51] -pratchett.freenode.net- *** Looking up your hostname...
[6:51] -pratchett.freenode.net- *** Checking Ident
[6:51] -pratchett.freenode.net- *** Found your hostname
[6:52] -pratchett.freenode.net- *** No Ident response
[6:52] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:52] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:52] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:10] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[12:03] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[13:07] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) Quit (Ping timeout: 240 seconds)
[13:19] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[13:30] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[13:44] * grahamtriggs1 (~Graham@144.173.122.69) has joined #duraspace
[13:45] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (Ping timeout: 248 seconds)
[13:48] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[13:52] * grahamtriggs1 (~Graham@144.173.122.69) Quit (Ping timeout: 260 seconds)
[16:08] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[17:13] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) Quit (Ping timeout: 240 seconds)
[17:14] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[19:53] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:55] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[19:55] <tdonohue> Hi all, quick reminder that our weekly DSpace Developers Meeting will be starting here in about 5 minutes. The agenda for today is all about upcoming 1.8.0 release: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-28
[19:55] <kompewter> [ DevMtg 2011-09-28 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-28
[19:56] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) has joined #duraspace
[19:56] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:00] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) Quit (Ping timeout: 240 seconds)
[20:00] <tdonohue> Hi all, it's time for our weekly DSpace Dev Mtg again. Today's agenda is all about 1.8.0 updates / known issues, etc. https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-28
[20:01] <kompewter> [ DevMtg 2011-09-28 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-28
[20:01] <tdonohue> First a brief announcement...I'll be out-of-office next week, so Robin will be convening our meeting on Weds, Oct 5
[20:02] <tdonohue> Beyond that, I was thinking we'd discuss any specific issues that need discussing, and then also do a quick review of 'unassigned' issues (see agenda) to see if we can get any volunteers or ideas for fixes
[20:03] <tdonohue> anyone have any specific 1.8 related issues to bring up at this time?
[20:03] <robint> Nothing in particular
[20:03] <robint> I'd be happy to go through the issues again as we did last week
[20:03] <hpottinger> there's been talk about an RC2...
[20:03] <KevinVdV> Well I do have something but I would like to wait until I can get Mark Diggory in here
[20:04] <robint> hpottinger: Yes we will do an RC2 once most/all the issues are resolved
[20:04] <robint> Hopefully middle-late next week
[20:05] <tdonohue> sounds good on RC2 schedule
[20:05] <hpottinger> OK, I'm happy to load that up in our demo instance
[20:05] <robint> hpottinger: thanks, I'll keep you informed
[20:06] <tdonohue> Well, should we begin with a review of some of the "unassigned" issues that are still open & scheduled for 1.8.0 (just to try & find volunteers/ideas)? We can circle back around to other issues after that?
[20:06] <robint> sounds good
[20:06] <tdonohue> ok, first up, this is unassigned & discovered by a user during Testathon: DS-1022
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1022 ] - [#DS-1022] Cannot select an option from Authority Control in Chrome or FF - DuraSpace JIRA
[20:07] <tdonohue> It seems to be a javascript error, affecting at least Mirage (haven't tested in other themes)
[20:07] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:07] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[20:07] <tdonohue> anyone familiar enough with Authority Control stuff to look into Ds-1022 in more detail? Currently Authority Control is completely broken in XMLUI (at least with Mirage)
[20:08] <robint> Silly question but does it work in 1.7 ?
[20:09] <mdiggory> Yes we use it
[20:09] <tdonohue> no idea. I basically just confirmed this was a bug on demo.dspace.org site (someone had reported it to me). I haven't had time to do any further testing or investigation
[20:09] <robint> ok thanks
[20:09] <mdiggory> Mirage is a rewrite of the javascript portions of AC becuase... well.... they sucked
[20:09] <robint> I'll look into it
[20:10] <robint> Is it possible that it is just a config issue on the demo server ?
[20:10] <tdonohue> ok, assign Ds-1022 to robint. Sounds like @mire folks also have some past experience & may be a good resource
[20:11] <tdonohue> it could be a config issue -- I suspect it is either that, or a minor bug/typo in javascript (the choice-support.js file which throws the error -- see comments in Ds-1022)
[20:11] <robint> Ok thanks
[20:11] <tdonohue> Ok, next unassigned issue, also reported by a user during Testathon: DS-1025
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1025 ] - [#DS-1025] Mouseover any title in XMLUI displays COINS info (see Advanced Search or Browse by Title - DuraSpace JIRA
[20:12] <tdonohue> there was some discussion of this issue in the comments, but no one has claimed it or written a fix. Essentially, we probably shouldn't be displaying COINS info on mouseover
[20:12] <hpottinger> Hmm, I thought that's the way COINS works
[20:13] <mdiggory> Apparently theres some confusion on that its supposed to do
[20:13] <tdonohue> COINS just requires a <span> tag. But, it doesn't need to be wrapped around the title info (like it currently is)
[20:13] <mdiggory> yes, I think it is fine to move it out of the title.
[20:13] <tdonohue> I think the XMLUI should work like the JSPUI currently does (where COINS is just in a <span> that has a non-breaking space)
[20:14] <robint> Famous last words but it sounds like a fairly simple fix
[20:14] <tdonohue> it should be simple. It's already doing the "right thing" in JSPUI. We just need to replicate that concept in XMLUI
[20:15] <mdiggory> has to happen in three places I think
[20:15] <mdiggory> dri2xhtml, dri2xhtml-alt, themes/mirage
[20:15] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[20:16] <tdonohue> yea, the hardest part here may be tracking down all the places that generate COINs for XMLUI. But, I think mdiggory has listed all or most of them. Any volunteers?
[20:17] * hpottinger reopens the internal ticket from long ago and links it to Ds-1025
[20:17] <hpottinger> I'll take a look at it, this has always bugged me
[20:17] <robint> I've just cut and pasted this conversation into the issue
[20:18] <tdonohue> thanks hpottinger. Feel free to claim DS-1025. If you run into issues, let us know. Hopefully it will be a relatively easy fix though :)
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1025 ] - [#DS-1025] Mouseover any title in XMLUI displays COINS info (see Advanced Search or Browse by Title - DuraSpace JIRA
[20:18] <tdonohue> ok, next unassigned issue: DS-1034 (again reported during Testathon)
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1034 ] - [#DS-1034] Incorrectly active breakcrumb links (XMLUI) - DuraSpace JIRA
[20:19] <mhwood> I was just looking at this, but haven't tracked down the sources of the trail elements yet.
[20:19] <tdonohue> PeterDietz are you already looking at this? Or were you just investigating what other sites do?
[20:20] <kshepherd> sorry, late as always, but i'm sure that Yin YIn (a dev i work with) and Bill from MIT had been looking at the CoINS template problems
[20:20] <kshepherd> i will chase it up
[20:21] <tdonohue> kshepherd -- get in touch with hpottinger there too, he's claimed the issue. I'm sure between you all someone will figure it out :)
[20:21] <tdonohue> as for Ds-1034 -- mhwood, looking into XMLUI theme code, the Trail is generated by "dri:trail" template, I believe
[20:21] <tdonohue> not sure what has to change in that template though
[20:21] <hpottinger> haven't claimed it yet, it's all yours if you want it, kshepherd
[20:22] <mhwood> Yes, but it's being told that the terminal trail element has a target. That's being generated in Java code somewhere, I think.
[20:22] <kshepherd> hpottinger: heh, go for gold! this was possibly an older or unrelated bug i'm thinking of
[20:22] <mdiggory> I'm looking at the code now, theres about 6 spots to just move the span and call to rendercoins down a few lines
[20:22] <kshepherd> hpottinger: but there might be some older discussions/patches that will help you, so i'll ask around
[20:23] <tdonohue> well, mdiggory, if you've found the resolution to Ds-1025, feel free. :) Or pass it off to hpottinger
[20:23] <kshepherd> the prolbem was that where we want to display/call the coins templates, we didn't have access to the DIM
[20:23] <kshepherd> or something
[20:23] <kshepherd> i think
[20:23] * hpottinger is willing to pull the levers, and will happily apply patches all day
[20:24] <tdonohue> any thoughts on DS-1034, or volunteers to investigate?
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-1034 ] - [#DS-1034] Incorrectly active breakcrumb links (XMLUI) - DuraSpace JIRA
[20:25] <mhwood> I may as well keep going on Ds-1034
[20:25] <robint> Much appreciated mhwood
[20:25] <tdonohue> mhwood -- one other idea on Ds-1034 -- maybe just tweak the template to not display the 'target' link for the last element in the trail? You may be able to fix this with some fancy XSLT :)
[20:26] <tdonohue> (just a thought)
[20:26] <mhwood> 'twould be simpler, but I think it may be against the WING spec.
[20:27] <tdonohue> Ok, mhwood will claim Ds-1034 and investigate it further
[20:27] <tdonohue> (I admit, I haven't looked at the WING spec recently, so you may be correct!)
[20:28] <tdonohue> Ok, it looks like that's the last "unassigned" issue which is scheduled for 1.8.0
[20:28] <mhwood> I'll keep that in mind.
[20:28] <robint> Thanks to all volunteers
[20:28] <tdonohue> Does anyone have any specific issues they'd now like reviewed? Or should we just go through the full list & get quick/brief updates on all?
[20:28] <tdonohue> (yes! thanks to volunteers!)
[20:29] <KevinVdV> DS-599
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-599 ] - [#DS-599] SOLR statistics file download displays all files and not only those in the Bundle Original - DuraSpace JIRA
[20:29] <KevinVdV> I know most of you don't know much about solr but I'm not sure on how to handle updating old bitstream hits
[20:29] <kshepherd> i know everyone's sick of ds-768 by now.. ;)
[20:29] <kompewter> [ https://jira.duraspace.org/browse/ds-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:29] <tdonohue> Lets start with DS-599 first...we'll get to your's next, kshepherd
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-599 ] - [#DS-599] SOLR statistics file download displays all files and not only those in the Bundle Original - DuraSpace JIRA
[20:30] <KevinVdV> So with the help of Peter Dietz I was able to create a solution for "new" bitstream hits but I'm not sure on how to proceed with updating all those old bitstream hits
[20:31] <KevinVdV> Doing it the "easy" way by looping over all the documents & adding the bundle is just waaaaaaay to slow
[20:31] <tdonohue> how "slow" is waaaay slow (just curious). Are we talking hours? days?
[20:32] <mdiggory> My recommendation in the jira ticket was to explore gerenating a csv file with all the update within them and running a batch update against solr, is that as slow?
[20:32] <mhwood> How fast does it have to be? The data are incorrect now, and they get steadily better until the task completes.
[20:32] <KevinVdV> Well it all depends on how many hits you have but my personal findings when talking about a couple milion hits we are talking about a week ...
[20:33] <tdonohue> yuck. ok, that is slow :)
[20:33] <mdiggory> updates against a large solr index are generally going to degrade query performance as well.
[20:33] <robint> Going off at a slight tangent, but correcting stats data can be contentious
[20:33] <KevinVdV> I will need to look into the csv update but are you sure you can add conditions to the csv updating ?
[20:33] <mdiggory> robint: you had to go there...
[20:33] <tdonohue> robint, even if "correcting" is just adding in a Bundle name to existing stats?
[20:34] <robint> mdoggory: :)
[20:34] <robint> tdonohue: thats a good point
[20:35] <mdiggory> KevinVdV: think of the csv file row as an intermediary form of the solr Document your submitting.
[20:35] <robint> tdonohue: although are we not talking about actually correcting the numbers to ignore non 'original' bundles ?
[20:35] <mdiggory> the objective would be to (1) dump the solr index to csv (2)adjust teh csv file to include bundles (3) rebuild a new solr core off the csv file
[20:36] <mdiggory> it would be done offline and it wouldn't be an "update", it would be completely rebuilding a new core
[20:37] <tdonohue> yea, in the end, that actually is what happens, robint. But the only real "correction" in Solr is that we want to add a "bundle" field. However, the Solr Queries that build that stats pages would then use that field to filter on (if I understand this all completely -- someone correct me if I'm wrong)
[20:38] <mdiggory> KevinVdV, the question has more to do with where the cost is, are you guys commiting after every SolrDocument update, or are you batching the updates, then commiting after a block of them are completed.
[20:38] <robint> tdonohue: Just reread it and get it now, bit slow on the uptake
[20:38] <mdiggory> tdonohue: you got it right...
[20:39] <tdonohue> mdiggory -- that CSV approach is interesting to me (as long as we test it & prove it is "stable", i.e. no data will be lost). It seems like it could be useful for any sort of future "updates" to the stats data.
[20:39] <KevinVdV> At the moment the auto commit is used markd
[20:39] <KevinVdV> I am willing to check out the CSV update in the weekend
[20:40] <mdiggory> right, it could even be "streamed" dumping from the core, processing in-memory and streaming to the new core.
[20:40] <mdiggory> I assume autocommit defaults to every update...
[20:40] <mdiggory> thats going to slow things down
[20:41] <KevinVdV> Not sure I THINK that the autocommit happens every x number of minutes
[20:41] <KevinVdV> Think it is 15 (not sure though)
[20:41] <mdiggory> if its the default SolrLogger that your using, then I think your right
[20:42] <tdonohue> so, it sounds like the CSV approach is worth investigating, and perhaps looking at autocommit settings (and whether a tweak there could help performance or not)
[20:43] <KevinVdV> So FYI I will attempt to look into the CSV stuff during my weekend & will report my fidings on monday
[20:43] <KevinVdV> findings
[20:43] <tdonohue> Sounds great, KevinVdV. Thanks again for your hard work on this!
[20:43] <robint> It would be nice if whaatever we settled on didn't have to be run as part of a 1.8 upgrade
[20:43] <robint> but could be done at leisure afterwards
[20:44] <mdiggory> its not so much a csv approach though, IMO, its not trying to update the current statistics core, and instead building a new one to replace the current statistics core.
[20:44] <robint> ...in an ideal world :)
[20:44] <tdonohue> right, I'd agree robint. It'd be nice it have a script to "upgrade-my-stats" or something like that, which you can run whenever you need it (assuming you are using Discovery Stats, obviously)
[20:45] <KevinVdV> Well robint my code is backwards compatible so if you do not run the script you will receive all bitstream hits for the OLD stats & for the new ones only the ORIGINAL ones will be counted
[20:45] <tdonohue> Ok, shall we swing back to DS-768 (everyone's favorite issue) & kshepherd?
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:46] <mdiggory> Some pointer on manipulating the Solr cores programatically...
[20:46] <mdiggory> http://wiki.apache.org/solr/CoreAdmin
[20:46] <kompewter> [ CoreAdmin - Solr Wiki ] - http://wiki.apache.org/solr/CoreAdmin
[20:47] <mdiggory> See API guide at the bottom of the page
[20:47] <tdonohue> mdiggory -- add to Ds-599 comments maybe? Just want to keep the discussion moving along here...so we can get to other issues that may need discussion as well
[20:47] <mdiggory> CoreAdminHandler
[20:48] <tdonohue> Ok, back to DS-768. kshepherd, what's the latest? Are more eyes/help necessary?
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:48] <kshepherd> sorry guys, got to run to a lecture
[20:48] <kshepherd> the latest is just... i still havne't heard anyone say "it's broken"
[20:49] <kshepherd> but i haven't heard "it works" either
[20:49] <kshepherd> so i'm still kinda nervous ;)
[20:49] <kshepherd> (i think it works though)
[20:49] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) Quit (Ping timeout: 240 seconds)
[20:49] <robint> kshepherd: Is it committed ? I'll do some testing
[20:49] <tdonohue> ok, cool (feel free to run kshepherd if you gotta go). Anyone here have time to test this?
[20:50] <tdonohue> is this up on hpottinger's testathon server?
[20:50] <hpottinger> I'm trying to get the patches applied to my testathon server
[20:50] <kshepherd> robint: the patch to XMLUI isn't committed, but the cocoon serclet service impl is released as a maven artifact (thanks to Mark D)
[20:50] <kshepherd> sorry gotta go
[20:50] <robint> No worries
[20:51] <tdonohue> Ok, so sounds like next step is really to test this out on a central site (a testathon server perhaps), or commit patch & then we all test it out locally
[20:52] <robint> I'll apply the patch and if it doesn't appear to break anything then I'll commit it
[20:52] <tdonohue> sounds like a good plan. Committing it will force us all to test it :) Plus, we can push it out to both testathon servers easier from SVN trunk.
[20:53] <tdonohue> if we hit on major problems, we can always "undo" the patch later on. But, I for one trust kshepherd's instinct on this :)
[20:54] <hpottinger> trunk compiles with the patches in place, that's about all I can report at this time, it'll auto-deploy tonight, around 10pm CST
[20:54] <tdonohue> cool!
[20:54] <robint> thanks hpottinger
[20:54] * hpottinger crosses his fingers
[20:55] <tdonohue> Ok, any other last issues to bring up? I'll note that DS-959 now has a "fix" (just in patch form so far). I'm doing some final testing to make sure it's a complete fix (I think it is). If anyone has any comments, feel free to send my way. I'll likely commit it tomorrow sometime
[20:55] <kompewter> [ https://jira.duraspace.org/browse/DS-959 ] - [#DS-959] XMLUI login failure when using Tomcat 7.0.16 - DuraSpace JIRA
[20:56] <robint> Good fixing tdonohue
[20:56] <KevinVdV> Indeed
[20:57] <tdonohue> Also, ablemann reminded me on #dspace about DS-900 and DS-901 (both documentation suggestions). It would be nice to get some better docs around these both -- if not before 1.8.0, then shortly thereafter on the Wiki.
[20:57] <kompewter> [ https://jira.duraspace.org/browse/DS-900 ] - [#DS-900] Create documentation for Updating a DSpace installation from source - DuraSpace JIRA
[20:57] <kompewter> [ https://jira.duraspace.org/browse/DS-901 ] - [#DS-901] Add documentation about overlays - DuraSpace JIRA
[20:58] <tdonohue> I'd be willing to try and tackle Ds-901 myself (since I had an presentation on this back at OR09). But, I'd love help on Ds-900 or any other local practices you've all developed
[20:58] <robint> Should we schedule them for 1.8 ? We can always reschedule them if they don't get done.
[20:58] <tdonohue> we might want to..just as a reminder.
[20:58] <tdonohue> (I admit, they had slipped my mind)
[20:59] <mdiggory> I have to run guys, but an aside, I am trying to get the tombstone patch up before the next meeting for review.
[20:59] <robint> Thats them scheduled
[21:00] <tdonohue> Any parting thoughts for today? Personally, I think 1.8.0 is looking great so far. A few issues left open, but we are tackling them quickly overall
[21:00] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[21:00] <hpottinger> hey, speaking of documentation, I'd love to know what the current best practice is for using Maven to produce development, staging, production versions, since Maven 3 has done away with profiles.xml
[21:00] <robint> mdiggory: I'm hoping to cut RC2 late next week
[21:01] <robint> mdiggory: feel free to throw patches my way if you want a reviewer
[21:01] <mdiggory> hpottinger: put it in your settings.xml or in your pom.xml directly
[21:01] <mdiggory> ok, thnx, bye
[21:01] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[21:01] <mhwood> Someone just offered an ru_RU localization (on dspace-tech?) Too late for 1.8.0?
[21:01] <tdonohue> yea, hpottinger. I'd like to see us eventually document best practices/tips with that as well.
[21:02] <tdonohue> Translations can always come in later as needed....so, definitely not too late for 1.8.0. We just need a quick verification that all the tags/properties seem to be included
[21:03] <robint> mhwood I saw Claudia update the German translation so maybe we should do a lnag packs release anyway
[21:04] <robint> I've got to go. Thanks all
[21:05] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Quit: Page closed)
[21:05] <KevinVdV> Go to run cya you all, will hopefully be reporting on D S 599 on monday
[21:05] <tdonohue> yep. Language packs are also released Asynchronously (always have been). So they can be updated even after 1.8.0 as needed. But, we should do another lang packs release if there are recent changes to get out there before 1.8.0
[21:05] <KevinVdV> Go == Got
[21:05] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) Quit (Quit: KevinVdV)
[21:05] <tdonohue> Yes, meeting is officially closed all. Have a great week! (two weeks, actually...I'll be out next week, but still available via email as needed)
[21:05] <mhwood> TIme for me to leave, also. Thanks!
[21:06] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has left #duraspace
[21:08] <hpottinger> Thanks, bye, all!
[21:08] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[21:16] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[21:17] <hpottinger> and I'm back, just for a sec, wanted to point out that there's a committer nomination vote in play right now, if you've missed it
[21:19] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Client Quit)
[21:37] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Quit: keithgilbertson)
[21:46] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[22:02] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[22:04] * keithgilbertson (~keithgilb@207.138.47.158) has left #duraspace
[22:06] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.