Timestamps are in GMT/BST.
[0:44] * Disconnected.
[0:44] -card.freenode.net- *** Looking up your hostname...
[0:44] -card.freenode.net- *** Checking Ident
[0:44] -card.freenode.net- *** Found your hostname
[0:44] -card.freenode.net- *** No Ident response
[6:44] -asimov.freenode.net- *** Looking up your hostname...
[6:44] -asimov.freenode.net- *** Checking Ident
[6:44] -asimov.freenode.net- *** Found your hostname
[6:44] -asimov.freenode.net- *** No Ident response
[6:44] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:44] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:44] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:18] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:29] * JesseDhammu (0e8b3ac2@gateway/web/cgi-irc/kiwiirc.com/ip.14.139.58.194) has joined #duraspace
[12:29] * JesseDhammu (0e8b3ac2@gateway/web/cgi-irc/kiwiirc.com/ip.14.139.58.194) Quit (Client Quit)
[13:00] * tdonohue (~tdonohue@c-73-45-154-218.hsd1.il.comcast.net) has joined #duraspace
[13:43] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) has joined #duraspace
[14:39] * peterdietz_ (uid52203@gateway/web/irccloud.com/x-qpxrbpzyeasznvnx) has joined #duraspace
[14:46] * peterdietz (uid52203@gateway/web/irccloud.com/x-nitgvpbtgkcnbxnd) Quit (*.net *.split)
[14:46] * peterdietz_ is now known as peterdietz
[15:00] <tdonohue> Hi all, welcome, it's time for our weekly DSpace Developers meeting... agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-07-01
[15:01] <tdonohue> If the agenda for this week seems like a copy of last week's, that's because it mostly is. Unfortunately, we still need to get help squashing some bugs for a 5.3 release
[15:01] * cknowles (~cknowles@cpc67742-sgyl32-2-0-cust219.18-2.cable.virginm.net) has joined #duraspace
[15:02] <tdonohue> here's the outstanding bugs we are still waiting on for a 5.3... DS-2602, DS-2603, DS-2593, DS-2614
[15:02] <tdonohue> hmmm...and kompewter is missing, it seems
[15:03] <tdonohue> I just woke up kompewter...should be here in a minute
[15:03] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[15:03] <tdonohue> here's the outstanding bugs we are still waiting on for a 5.3... DS-2602, DS-2603, DS-2593, DS-2614
[15:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2602 ] - [DS-2602] Clicking on a letter when browsing by title or year when browsing by date does not work - DuraSpace JIRA
[15:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2603 ] - [DS-2603] The citation_pdf_url metadata is null when it shouldn't - DuraSpace JIRA
[15:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2593 ] - [DS-2593] Withdrawn items remain in OAI-PMH until the next full re-import - DuraSpace JIRA
[15:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2614 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[15:05] <tdonohue> Latest status I recall is that mhwood was looking to take 2603 and possibly 2614. 2602 is a simple "revert a PR" which anyone can claim quickly. 2593 had a volunteer to investigate in kshepherd
[15:05] <tdonohue> but, it looks like all four are still awaiting resolution...and we've been having a lot of complaints (on dspace-tech) about DS-2602 specifically, so it'd be good to get 5.3 out the door
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-2602 ] - [DS-2602] Clicking on a letter when browsing by title or year when browsing by date does not work - DuraSpace JIRA
[15:06] <mhwood> pbecker has done a PR for 2614, I'm going to review the code.
[15:06] <tdonohue> yep, 2603 has a PR too, just needing test/review
[15:06] <tdonohue> 2602 is reverting a PR
[15:07] <tdonohue> 2593 is the only one that still needs a PR / development help
[15:08] <tdonohue> Do we feel we can make some more headway in the next week here? Anyone else willing to help chip in on a 5.3 release here? I cannot imagine many folks would want to run 5.2 as-is (especially with the 2602 bug)
[15:10] <tdonohue> hmm...lots of silence here. Seems like we have a lack of resources on helping to move 5.3 forward....or just not enough time amongst ourselves for a "final push"
[15:11] <mhwood> Awfully quiet in here.
[15:12] <mhwood> There was a netsplit a few minutes ago.
[15:12] <tdonohue> I'll see if I can find spare cycles myself to try and chip in too...not sure whether there will be much of my time in the next week though, we'll see
[15:13] <peterdietz> Okay, so help needed in testing some PR's, and one issue is still at large
[15:13] <mhwood> I need to finish off some stuff for another project and get back onto DSpace things. I'll try to make progress on those tickets this week.
[15:13] <tdonohue> yep, exactly. We basically have these 4 tickets. Even if we could get 3 of the 4 done, we'd have a good enough 5.3. But, if we could push to get all 4 done, that's all we really need for a 5.3
[15:15] <tdonohue> If we are not able to make much headway, I think we *have* to release a fix to DS-2602 very soon. We are getting complaints on mailing lists as people upgrade to 5.2, and frankly we need to fix our browsing problems asap
[15:15] <kompewter> [ https://jira.duraspace.org/browse/DS-2602 ] - [DS-2602] Clicking on a letter when browsing by title or year when browsing by date does not work - DuraSpace JIRA
[15:15] <tdonohue> The other 3 tickets would be nice to add to the mix. But, 2602 is the biggest cause for complaint
[15:16] * ccordovas (~ccordovas@pc-196-42-46-190.cm.vtr.net) has joined #duraspace
[15:17] <tdonohue> Ok, not sure there's much else I can say here...just that we could really use more help. If anyone is planning on upgrades to 5.2 soon, you probably should think about helping us fix some of these "obvious bugs" so you can just upgrade to 5.3 instead
[15:17] <mhwood> Oops, already went 5.2 here. So I guess we should be very motivated to get 5.3 out!
[15:18] <cknowles> I will try and look at 2602 but will probably be early next week as only back today from leave.
[15:18] <tdonohue> mhwood: yep, if your users haven't noticed some of this issues already, they likely will soon (especially 2602)
[15:18] <cknowles> I don’t do a straight ‘yes’
[15:18] <tdonohue> cknowles: still, thanks!
[15:19] <tdonohue> Ok, so that's a few responses! I'll also see if I can find an hour or two to dig in on these either tomorrow or early next week. Thanks all
[15:20] <hpottinger> tell you what, we're gearing up for an upgrade to 5_x, I will pull the commits from the available PRs into a branch and test a bit, if they work I'll just roll them into our fork of 5_x and keep going
[15:20] <tdonohue> We can move along now, I guess. My usual reminders on 6.0 are next ;)
[15:21] <tdonohue> 1) We're still looking for Release Team members (you all already know that)
[15:21] <tdonohue> 2) We're still looking for a few folks to try and help remove the old Browse/Search (DBMS / Lucene) in the 6.0 codebase. If you find time in the coming weeks/month, let me know
[15:22] <tdonohue> 3) I'm still working with @mire to schedule the "Service API + Hibernate" discussion. I'm waiting to hear back on a date that works best for them...I'm going to ping them again today, so we can try to get this moving forward for review for possible 6.0 inclusion
[15:24] <tdonohue> Another thing to mention regarding 6.0. I was contacted by CNRI (folks who run Handle.net) about trying to get our Handle Server upgraded to a more recent version (we're on 6?, and they are about to release 8). This relates directly to DS-2153
[15:24] <kompewter> [ https://jira.duraspace.org/browse/DS-2153 ] - [DS-2153] Move to a more stock Handle service, implementing proper separation of concerns - DuraSpace JIRA
[15:24] <tdonohue> So, if anyone is interested in that sort of work, it also might be a "nice to have" for 6.0 (or relatively soonish)
[15:25] <tdonohue> Essentially though it sounds like the largest user of "old-style" handles are DSpace users... CNRI is migrating things to a newer platform (with version 8), which will still work with "old-style" handles, but they'd like to see us move to version 8, if we can
[15:26] <mhwood> I'm interested but don't know when I can work on it. I'll note that 2153 should facilitate such upgrades, since we could just run the current stock resolver.
[15:26] <tdonohue> (I don't have much more info than that from CNRI, yet, unfortunately. But, version 8 is supposed to be out in mid-to-late July)
[15:26] <mhwood> I for one need to find out more about these "new-style handles".
[15:27] <tdonohue> +1 mhwood. To be honest, I think upgrading our Handle server would almost require 2153 (not sure how easy the upgrade would be without it)
[15:28] <tdonohue> What I know about the "new style handles" is that it's mostly a change in management of the centralized handle service...they are handing it over to a different "entity" www.dona.net. Going forward, handles minted by CNRI will be prefixed "20.[handle-prefix]" (e.g. 20.12345). But, old prefixes will still work
[15:29] <mhwood> The way we do Handles now works well for us, but it also shows a pattern I've seen around DSpace: a number of dependencies are treated as if DSpace is the only reason you would have them. That's not true at every site. I think we can do better at separating concerns.
[15:30] <tdonohue> More info will likely be coming from CNRI on mailing lists. I've only just heard about this, and I'm encouraging them to send us more info so we can get it out to everyone (and possibly also then quickly find a volunteer to cleanup how we deal with Handles)
[15:30] <mhwood> OK, so new-style look the same except for internal details, and old still work.
[15:31] <cknowles> will this change the invoicing of handles as well?
[15:31] <tdonohue> yes, that's my understanding mhwood. There will also likely be a new, updated service agreement from CNRI (cause of mgmt changes), but I don't know any more than that.
[15:31] <mhwood> Are there MLs we should be on for this? (I suppose they might consider dspace-* a good place to make announcements like this.)
[15:31] <tdonohue> cknowles: possibly, all I know is a new service agreement. Not sure where invoicing will happen. Literally, I'm summarizing a 3 paragraph email I received on Monday...and I've asked for more info too ;)
[15:32] <tdonohue> mhwood: I've encouraged them to either post to dspace-* lists, or send more info that we can post on their behalf.
[15:33] <tdonohue> But, all this being said, it points to us thinking more about if there's a way to make DS-2153 happen sooner rather than later, so we can upgrade to the latest Handle Server, and also (eventually) better support folks who *don't* want to use Handles.
[15:33] <kompewter> [ https://jira.duraspace.org/browse/DS-2153 ] - [DS-2153] Move to a more stock Handle service, implementing proper separation of concerns - DuraSpace JIRA
[15:34] <tdonohue> I'm hoping that once this info is made more public by CNRI, that we can use it to "light a fire" to help make these changes happen
[15:35] <tdonohue> I believe those are all my updates on 6.0 stuff. Anyone else have anything to talk about regarding 6.0, or ideas/projects you'd like to see considered? (Or volunteers for RT?!)
[15:37] <mhwood> Note that at this point *there is no RT*. No volunteers yet.
[15:37] <tdonohue> OK. I'm getting the feeling here that Summer is just swamped for most folks...both 5.3 and 6.0 seem to be moving rather slowly thus far
[15:37] <tdonohue> correct, we have no RT at all. Which is a shame, since it's already July. :(
[15:38] <tdonohue> I also plan to bring this up at our next DSpace Steering Meeting (next week) as a concern with 6.0, to see if we can find folks that route
[15:40] <tdonohue> For now, moving along to the RoadMap / new UI Prototyping work. It has also been progressing a bit slowly, as we've had a lot of folks on holidays/vacations the last month
[15:41] <tdonohue> But, the latest news is that Jonathan Markow & I are meeting later this week or early next (once he is back from his vacation).... we've been talking via email about forming a "UI Working Group" to help us finalize the UI prototyping process & kick off the prototypes in general.
[15:42] <tdonohue> That "UI Working Group" would consist of one individual from each institution which has expressed an interest in taking part. It'd basically be a coordination group, to help ensure none of these prototypes are duplicative, and that we are all doing the work in the open & in a collaborative fashion
[15:42] <tdonohue> I'm hoping we'll get this group formed in the next week or so, and then we can work towards finalizing the prototypes / teams, etc
[15:43] <tdonohue> I still do have my own (personal) rough schedule drafted up at: https://wiki.duraspace.org/display/DSPACE/Design+-+Single+UI+Project (would need to be verified by this Working Group though)
[15:43] <kompewter> [ Design - Single UI Project - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Design+-+Single+UI+Project
[15:43] <mhwood> Meanwhile, is there a definitive list of what the New UI should be/do? Not down to individual DSpace features; more like presentation features.
[15:44] <tdonohue> I also have started drafting up what the Prototype Process *might* look like (again would need verification by Working Group): https://wiki.duraspace.org/display/DSPACE/Prototyping+a+Future+UI
[15:44] <kompewter> [ Prototyping a Future UI - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Prototyping+a+Future+UI
[15:45] <tdonohue> mhwood: some of those details are on that "Prototyping a Future UI" page...it lists what would be *required* out of a new UI technology. It's based off the feedback from the "Brainstorms for a Future UI" page
[15:45] <mhwood> OK, thanks.
[15:45] <tdonohue> but again, it's only my brain dump so far...this content has not been run by anyone else yet...but, please feel free to send feedback on it!
[15:47] <cknowles> As kshepherd mentioned last week, we have been trying to document the existing UI and it’s calls to the core code not got far yet though
[15:47] * ccordovas (~ccordovas@pc-196-42-46-190.cm.vtr.net) Quit (Ping timeout: 264 seconds)
[15:47] <tdonohue> cknowles: once you have something, please do send it along. I think it'd be an excellent addition to this whole process. We also might be able to find others to chip in (via this "UI Working Group" or similar)
[15:48] <hpottinger> I mentioned to cknowles that the Freemarker JIRA might be a resource, but it apppears to not be entirely public
[15:48] <cknowles> tdonohue will do
[15:48] <mhwood> That sounds quite useful. We need to be able to see patterns and discover what we can "lean out" of the UI into the backend.
[15:49] <hpottinger> old FreemakerUI JIRA: https://jira.duraspace.org/browse/DWMVC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
[15:49] <kompewter> [ Log in - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DWMVC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
[15:49] <cknowles> need to find away to document without it becoming a huge task
[15:49] <tdonohue> hpottinger: Freemarker JIRA? Oh, yea, that was locked down (to Committers only) to avoid confusion from users wanting to submit JIRA tickets for DSpace. Do we really think there's use in a 4-5 year old bunch of tickets?
[15:49] * ccordovas (~ccordovas@pc-196-42-46-190.cm.vtr.net) has joined #duraspace
[15:49] <hpottinger> Any chance we can make a single exception for cknowles since she's helping us out?
[15:50] <tdonohue> hpottinger: and to be fair, there's literally 11 tickets in the "Freemarker JIRA" project. Not sure they are of that much use
[15:50] <tdonohue> I can give cknowles access sure
[15:50] <hpottinger> just repeating peterdietz, I don't know what's in there
[15:50] <tdonohue> but, as mentioned, there are just 11 tickets
[15:50] <tdonohue> (and I don't see any that look obviously useful in scanning their titles)
[15:51] <hpottinger> they might be useful as conversation starters with peterdietz or grahamtriggs
[15:51] <hpottinger> they are the most recent explorers of the new UI frontier
[15:52] <tdonohue> cknowles: you now should have access to https://jira.duraspace.org/browse/DWMVC/ (and all Committers should already have access there)
[15:52] <kompewter> [ Log in - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DWMVC/
[15:53] <cknowles> tdonohue, thanks
[15:53] <tdonohue> Just for context (for anyone listening)...this was an old Google Summer of Code project (from 2011) to build a new DSpace UI using Spring WebMVC and Freemarker templates: https://wiki.duraspace.org/display/DSPACE/WebMVC+%28Freemarker%29+UI
[15:53] <kompewter> [ WebMVC (Freemarker) UI - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/WebMVC+%28Freemarker%29+UI
[15:53] <tdonohue> The code is all still in GitHub too at: https://github.com/DSpace/webmvc (But it hasn't been touched since 2011)
[15:53] <kompewter> [ DSpace/webmvc · GitHub ] - https://github.com/DSpace/webmvc
[15:54] <peterdietz> wow, that was 4-5 years ago. Still stuck on UI problems
[15:54] <mhwood> :-(
[15:54] <cknowles> :(
[15:55] <tdonohue> There likely may be some useful concepts there, sure...but the code is probably a bit old at this point (but might be usable as a prototype of some sort, who knows)
[15:56] <tdonohue> yep, still stuck on UI problems. Unfortunately that project never gained "legs" either so it was basically abandoned after GSoC
[15:56] <peterdietz> I don't know what else we're accomplishing today, but one of my UI approaches in the past has been thinking of a hybrid UI. Where you might present to the anonymous public a simpler browse oriented UI, and once you click on login, you get kicked over to a stable thing like XMLUI
[15:57] * tdonohue was at the end of the agenda, so there's nothing else to mention anyhow.... I was just going to ask for ideas/thoughts/brainstorms in general on UIs / RoadMap
[15:58] <mhwood> Also keep in mind that submitters, consumers, and administrators have different views of the product. There's no reason they have to use the same monolithic UI in their different roles.
[15:58] <tdonohue> peterdietz: seems plausible. I've also heard that mentioned in another way of having a browse/search/access UI AND an Admin UI. There's no reason they need to be the same thing, but we may not want it to be a jarring change when jumping between UIs
[15:59] <cknowles> peterdietz I think it is useful to think of the sections of the UI: 1) public view (search, item pages) 2) submission workflow 3) Admin functions
[15:59] <peterdietz> Thinking about gaining legs... Usually if something isn't in the core, then it has little chance of getting used. i.e. without REST, it had limited use (CRIS might also be in this situation). So, maybe a new UI would have to get into the core early to get adopted/used. And then how to you eventually cut the legs off of the old UI's
[16:00] <cknowles> If the UI all use bootstrap can switch between without it being obvious to the enduser
[16:00] <cknowles> though would be interested to know how many users most DSpace installations have for the admin screens
[16:00] <mhwood> Is there a need for it to be non-obvious, if you're changing hats anyway?
[16:01] <cknowles> not necessarily between public screens and admin
[16:02] <tdonohue> Using a common presentation layer like "bootstrap" might be enough...but, if you had separate public/submit/admin UI with entirely different layouts / menus, that seems like it would garner complaints :)
[16:02] <hpottinger> One not quite so obvious thing is that we need all UIs to work reliably in a similar fashion with things such as character encoding
[16:03] <mhwood> "Oh, a string of characters. Here, do something with this, common business logic."
[16:04] <hpottinger> right, but if one UI says, oh, lets defang this string of characters before we store it, and another doesn't... or one works well with UTF-8 while the other doesnt... things get weird fast
[16:05] <mhwood> Stuff that doesn't belong in the UI, IMHO.
[16:05] <tdonohue> As a sidenote, I got bored late on Friday, and I started playing with Spring Boot + Thymeleaf (just to get more familiar with Spring Boot mostly). I have a rough experiment I'm going to post in GitHub soon (hopefully this week if I can clean it up and write a quick README) which could be the basis for a UI prototype eventually. It can connect to DSpace 5.x using the Java API and read data. Not much more than that tough.
[16:05] <cknowles> Gotta go, hpottinger I’ll mither you if I need help with vagrant-dspace ;)
[16:05] <hpottinger> well, maybe the UTF-8 does :-) but I agree, defanging doesn't
[16:06] <peterdietz> I don't see how bootstrap alone is enough of a "standard". Each template system is going to be radically different in how it accomplishes that. I suppose you could have a designer come up with "screens" of the 50 different functional aspects of a UI (login form, register user form, start a submission form, describe step form, upload step form, accept license
[16:06] <peterdietz> form, review submission screen, view collection screen, view item screen). So the 50 neccessary funcationalities, and then a sketch up of what each page should look like. You could then have one create each prototype to have all 50 screens, and look the same.
[16:06] * cknowles (~cknowles@cpc67742-sgyl32-2-0-cust219.18-2.cable.virginm.net) has left #duraspace
[16:07] <hpottinger> ooh, that'd be cool, a unified stylesheet... but... that's a lot of work for each prototype to manage, when only one can survive
[16:08] <tdonohue> peterdietz: you are right...it's not just bootstrap alone as a "standard"... but it'd be bootstrap + a common looking theme. I was mostly just suggesting bootstrap since it can then be themed in a similar fashion across access/deposit/admin UIs
[16:08] <tdonohue> +1 to the idea of a designer mocking up a look & feel. That's actually listed on the Single UI Project wiki page
[16:08] <hpottinger> but, using Bootstrap for *most* UI pieces would get us close
[16:09] <hpottinger> even in Mirage2 there are things that are in bootstrap but the old Mirage styles were retained (like pagination styles)
[16:10] * tdonohue notes we are "overtime" here obviously. I won't halt this discussion though, if folks want to continue brainstorms
[16:12] <mhwood> Mock-up sounds like a good first step, except...we are trying to support sites that don't want to follow the design. Not just restyling -- they want to move stuff around, remove and add stuff. Making room for that sort of thing is the difficult bit.
[16:12] <peterdietz> bootstrap is good to stick with. I would prefer to have consistent tools across variations. rather than bootstrap for user UI + 960gs for admin UI.. yuck. If we had a dspace-ui-template system. i.e. grails thing, and then you clone it to build a end-user-browse variant, then a admin-user-variant.. Sounds like heads. Or you could put it all into one big super
[16:12] <peterdietz> app
[16:13] <hpottinger> We could pick a common-ish template framework (maybe Velocity)? and hope that templates could be shared between prototypes?
[16:13] <tdonohue> I do think these ideas are all "on the table" for the new UI. There's no requirement that the new UI is one overarching UI. Also any technologies are still "on the table"... so if you have ideas of something you'd like to try out, maybe we could turn it into a UI prototype.
[16:14] <peterdietz> I'm thinking REST + building a DSpace SDK for various programming languages. Then php people can go to town, rails, java, javascript, ... I think people will want to have flexibility. DSpace will still need to have the one consistent out-of-the-box UI, but it could also support DSpace-as-a-repository-service
[16:15] <tdonohue> hpottinger: nice idea, but a part of me also wants to try *different* templating frameworks, to get a sense of which we like best. If we only look at Velocity (vs. Freemarker vs Thymeleaf) is that good enough? A part of me wants to prototype lots of options, then settle on a technology + templating framework we like best.
[16:15] <peterdietz> Anyways. The point is probably, do whatever prototype you want to do
[16:16] <tdonohue> yes, I'd say I'd encourage folks to prototype whatever they want (within the constraints). Hopefully we'll be able to better formalize the process & constraints once we get the UI Working Group established, etc
[16:16] <hpottinger> Yeah, I think probably Bootstrap is enough guidance, as long as we also say "don't run off the reservation... please actually *use* bootstrap"
[16:16] <tdonohue> +1 hpottinger
[16:16] <mhwood> It occurs to me that, whether we do one big UI or three? small ones, it might be good to e.g. explicitly make the admin. pages look different. Like the way the shell prompt changes color for root. Beware, you have ultimate power here!
[16:18] <mhwood> One other bit of guidance. Put two Post-Its at the top of your workstation display: "Share your CSS!" "Share your JavaScript!" This sort of stuff gets scattered all over, and it's hardly ever documented, so it's difficult for the new guy to figure out where things happen or why they are done that way.
[16:20] <tdonohue> mhwood: both are nice ideas... I do like the idea of making admin functions slightly differently styled. It's actually something like what Confluence does. When move over to Admin tools there's a banner at the top that says something like "You are accessing administrative functions"
[16:20] <tdonohue> When *I* move over to Admin tools...
[16:21] <tdonohue> In any case, I like the brainstorms here. It helps me get more ideas/feedback on things to consider in the process, etc
[16:22] <tdonohue> Any other final thoughts, or shall we officially close things up for today?
[16:23] <tdonohue> Sounds like it's time to close things up. Thanks for the discussion all!
[16:26] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[17:22] * ccordovas (~ccordovas@pc-196-42-46-190.cm.vtr.net) Quit (Read error: Connection reset by peer)
[17:35] * ccordovas (~ccordovas@pc-196-42-46-190.cm.vtr.net) has joined #duraspace
[18:56] * kdweeks (~Adium@kdweeksmac.lib.vt.edu) has joined #duraspace
[19:21] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) has joined #duraspace
[20:58] * kdweeks (~Adium@kdweeksmac.lib.vt.edu) Quit (Quit: Leaving.)
[21:01] * kdweeks (~Adium@2001:468:c80:a103:6959:e146:12fe:77d3) has joined #duraspace
[21:05] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[21:48] * tdonohue (~tdonohue@c-73-45-154-218.hsd1.il.comcast.net) has left #duraspace
[22:09] * kdweeks1 (~Adium@2001:468:c80:a103:6959:e146:12fe:77d3) has joined #duraspace
[22:11] * kdweeks (~Adium@2001:468:c80:a103:6959:e146:12fe:77d3) Quit (Read error: Connection reset by peer)
[22:31] * kdweeks1 (~Adium@2001:468:c80:a103:6959:e146:12fe:77d3) Quit (Quit: Leaving.)
[22:33] * hpottinger (~hpottinge@mu-160110.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.