Timestamps are in GMT/BST.
[5:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[5:44] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[5:51] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc__)
[6:12] * ksclarke (~kevin@adsl-235-136-109.clt.bellsouth.net) Quit (Quit: Leaving.)
[6:47] -card.freenode.net- *** Looking up your hostname...
[6:48] -card.freenode.net- *** Checking Ident
[6:48] -card.freenode.net- *** Found your hostname
[6:48] -card.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:02] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[10:15] * grahamtriggs (~graham@62.189.56.2) has joined #duraspace
[12:31] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[12:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[14:25] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:26] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:56] * ksclarke (~kevin@adsl-235-136-109.clt.bellsouth.net) has joined #duraspace
[15:23] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[15:24] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:28] * grahamtriggs (~graham@62.189.56.2) Quit (Remote host closed the connection)
[15:32] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[15:33] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:35] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Client Quit)
[15: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)
[15:36] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:36] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[16:07] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[16:07] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[16:54] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:54] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[16:54] * bradmc__ is now known as bradmc
[19:39] * ksclarke (~kevin@adsl-235-136-109.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[19:41] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:51] * PeterDietz (~PeterDiet@128.146.175.194) has joined #duraspace
[19:53] * cccharles (~chris@131.104.62.55) has joined #duraspace
[19:57] <tdonohue> Hey all -- DSpace Devel Mtg will begin at the top of the hour. Here's the general agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-05
[20:00] <tdonohue> Welcome back, all! I hope everyone had a good holiday and a happy new year. I think we all deserved a bit of a break after the 1.7.0 release :)
[20:01] <mhwood> I was happy to learn that I didn't miss two weeks' worth of meetings after all. :-/
[20:01] <tdonohue> I thought we'd start with a few JIRA reviews (first 15mins or so). We'll start with DS-641 -- here's the list of 'to-be-reviewed': https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-641+ORDER+BY+key+ASC
[20:01] * ksclarke (~kevin@adsl-235-136-109.clt.bellsouth.net) has joined #duraspace
[20:01] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) has joined #duraspace
[20:02] <tdonohue> yea, didn't miss anything mhwood :)
[20:02] <tdonohue> ok..here we go...JIRA reviews
[20:02] <tdonohue> Page does not exist: https://jira.duraspace.org/browse/DS-641
[20:03] * tdonohue for those just joining, agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-05
[20:03] * sandsfish (~sandsfish@75-138-180-114.dhcp.oxfr.ma.charter.com) has joined #duraspace
[20:04] * richardrodgers (~richardro@dhcp-18-111-15-218.dyn.mit.edu) has joined #duraspace
[20:04] <PeterDietz> re:DS-641, has there been browse/error.jsp in the past?
[20:05] <tdonohue> hi sandsfish & richardrodgers -- doing a JIRA review right now... starting here: Page does not exist: https://jira.duraspace.org/browse/DS-641
[20:05] <mhwood> There isn't one *anywhere* now.
[20:05] <sandsfish> thanks tdonohue
[20:05] <tdonohue> yea, definitely not there now
[20:05] <tdonohue> so, any volunteers to look into DS-641, and fix it (maybe for 1.7.1)?
[20:06] <PeterDietz> there is error/....jsp
[20:07] <tdonohue> PeterDietz -- yea, I'm assuming it should be pointing at *something* in error/, rather than at /browse/error.jsp (which doesn't exist anymore)
[20:08] <tdonohue> no volunteers for DS-641? Ok. I'll schedule it for 1.7.1, and hopefully we can find someone to fix this
[20:08] <tdonohue> IPAuthentication doesn't work with IPv6 addresses : https://jira.duraspace.org/browse/DS-642
[20:09] <PeterDietz> does this cause errors, or just that instantiating this class and not setting the error page doesn't work right
[20:09] <tdonohue> PeterDietz -- don't know -- we'd need a volunteer to investigate and resolve DS-641
[20:10] <mhwood> Since I'm the local IPv6 enthusiast, maybe I should take 642.
[20:10] <tdonohue> sure, mhwood. Sounds good to me!
[20:10] <mhwood> Will do.
[20:10] <tdonohue> Assign DS-642 to mhwood.
[20:11] <tdonohue> Enhanced embargo functionality : https://jira.duraspace.org/browse/DS-645
[20:13] <tdonohue> no code available for DS-645. Seems like it'd definitely have to wait for 1.8.0 at earliest (as it's an improvement). Anyone interested in working on this, or have something already brewing?
[20:15] <tdonohue> Ok, will leave DS-645 unassigned for now. Seems like a possible new feature, but would need a volunteer to investigate and look into potential implementation
[20:15] <PeterDietz> This is a worthy task to say the least.
[20:16] <tdonohue> We'll stop there for today with JIRA, as I'd like to move on to discussions of 1.7.0 and beyond :)
[20:17] <tdonohue> First off, again, hope you all had a good break (I know I did) & happy new year!
[20:17] <richardrodgers> happy new year all!
[20:17] <mhwood> Likewise.
[20:18] <tdonohue> I basically wanted to open things up for discussion of the 1.7.0 release process. What did we feel went well, what was problematic or harder than it should have been, etc.
[20:18] <tdonohue> or any other feedback anyone has around 1.7.0 release
[20:18] <PeterDietz> maven
[20:19] <richardrodgers> For the first time around in a time-based release, I'd say we did pretty well
[20:19] <tdonohue> Agreed. I think we did well with the time-based release! I'd like to see that continue :)
[20:20] <tdonohue> PeterDietz -- I also agree, Maven was a pain. But we now have a new, solid Release Procedure that works well: https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[20:20] <mhwood> I was wary of a fixed deadline -- I always am -- but it did go well.
[20:21] <tdonohue> Do others think the idea of a "fixed deadline" is worth continuing?
[20:21] <sandsfish> that's a great accomplishment tdonohue, and thanks to all who made it a reality.
[20:21] <mhwood> [cheers documented procedure]
[20:23] <tdonohue> thanks -- Mark Diggory started those docs, and I added tons of extra detail as I worked to fix the broken release process in the last few weeks. It's now "solid" (or at least it worked perfectly for me, the few times I ran through it for an RC and the 1.7.0 final)
[20:24] <tdonohue> One area I like to mention that I think we need to improve on: Documentation. Unfortunately, most of those docs didn't "get in" or get cleaned up until the final day(s) before the release. It gave Jeff Trimble & I a few very hectic days
[20:25] <richardrodgers> One thing we might do differently next time - have a real beta period. We jumped straight to release candidates....
[20:25] <tdonohue> so, we likely need to come up with a better Documentation process for the Wiki -- this was our first try, and it was a bit chaotic at the end.
[20:26] <PeterDietz> The pain of the process was that not all things finished before the imposed deadline. So going forward, it would be better to have code developed in the open, so that everyone can see progress of features
[20:26] <PeterDietz> ...but largely, most everything went smoothly, so i would recommend doing another timed release
[20:27] <mhwood> If documentation is lagging, yell for help. I'm definitely an enthusiast there too. Main problem: understanding the code well enough to document.
[20:27] <tdonohue> richardrodgers, how do you see the beta-process as being different than say an "RC1"? Is it just by name?
[20:28] <richardrodgers> tdonohue: not just name. What I have in mind is more like an 'early access' release, so adopters could really exercise stuff before it's cooked
[20:28] <grahamtriggs> picking up on mhwood's comment - now that we have a larger run up on future releases, we should pick a month for the release, and set a 'soft' target for the start of that month. We can never truly account for issues found in testing, so having the potential (at least relatively early on) to slip the release by a week or two but still make the schedule would be useful
[20:28] <tdonohue> mhwood, thanks. I think the bigger issue here was that we didn't have an organized "process" for making sure the docs were updated on the Wiki. What essentially happened was that I happened to notice 2 days before the release that most of the new main features had no docs in our wiki docs area. Cause a bit of scrambling to find the appropriate docs/people.
[20:29] <mhwood> Perhaps richardrodgers and PeterDietz are saying the same thing in different ways? A lot of code landed at the last minute, without much time for the community to comprehend it.
[20:29] <tdonohue> hmmm..yea, I understand now (and yea, I think richardrodgers & PeterDietz have similar points)
[20:29] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:31] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:31] <tdonohue> grahamtriggs: that's what we did with 1.7 actually. We had a "soft target" of Dec 4th initially...but, after the RC1 release issues, we moved back to our "hard target" of Dec 17.
[20:31] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[20:32] <tdonohue> (maybe that wasn't clear though -- it was initially documented as a soft target of Dec 4 in the Release Notes though -- and Peter & I talked around then and decided to push for Dec 17 instead)
[20:32] <mhwood> To me the difference between beta and RC is that in beta there's still time to reshape things, but an RC is pretty much set in stone except for bugfixes.
[20:33] <grahamtriggs> richardrodgers: practically, that just means we could/should have given a 'beta' tag to what was released as RC1. I think what's really interesting is how the psychology around this might work - are people more likely test a beta on the basis that it's a call to be tested, versus an RC where they might just think 'oh, it's nearly ready - I'll just wait for the release'?
[20:33] <tdonohue> So, going back to this idea of a "beta". Would we see this as occurring 1-2 months before we start RC1?
[20:34] <richardrodgers> grahamtriggs: yes, there are interesting psych dimensions. With a beta, people expect they can shape it, or nudge it, a bit
[20:34] <tdonohue> I think this idea of a beta is interesting one -- but obviously the begs the question of whether there will truly be enough time between beta and RC1 to allow for significant changes/testing to occur.
[20:35] <PeterDietz> so to test out code thats not fully cooked, either have a demo instance running running 1.7.x.embargo-feature, or just have an easy to follow recipe for installing your work-in-progress
[20:35] <richardrodgers> I believe if we can make releasing lightweight enough, we could have several (distinct) betas, e.g.
[20:36] <mhwood> How about this: each impending feature "goes beta" when preliminary code lands in the common repo. We are encouraged to expose new code as soon as it's somewhat functional.
[20:37] <tdonohue> mhwood -- interesting thought.. you and richardrodgers are both suggesting something akin to an "agile development" process (though for betas) -- more betas in shorter periods
[20:38] <mhwood> I have a Dilbert cartoon right here about Agile development. But I guess basically I'm saying that beta starts as soon as something new (not a bugfix) lands, and continues until features are frozen and RC begins.
[20:39] <tdonohue> So, I wonder if we'd truly get much community-wide testing in any *one* beta period (unless of course, it was a major feature most were highly interested in). Though, it does have the potential to try to get more folks involved earlier on (at least for major features)
[20:39] <grahamtriggs> I don't think that is going to particularly work - if the betas are too frequent you risk people ignoring them because they can't keep up
[20:40] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[20:41] <PeterDietz> hmm, but would the alpha/beta to test be a not-fully-cooked work in progress. I'm beating a dead horse, but I think a DVCS makes this easier for the developers to checkout each others code
[20:42] <grahamtriggs> A regular *deployment* that people can dip in and out of using to see what the current state of the code is would be useful, and is independent of having beta 'releases'
[20:44] <tdonohue> Not to be pessimistic :) but, I'd also point out we all (self included) have a track record of getting things into Trunk at the latest possible moment (1.7 isn't the first time this has happened). Do we feel a beta or perhaps several "stages" (where we just set a "beta1", "beta2" deadline) would encourage everyone to share code earlier?
[20:44] <richardrodgers> grahamtriggs: OK - but we still have to deal with the fact that trunk will at many times be unstable/incomplete...
[20:45] <tdonohue> or is something like PeterDietz's DVCS idea worth thinking about more in this context? (reminder to self: we need a special topics meeting on DVCS / git for deeper discussion)
[20:47] <mhwood> Trunk being incomplete between releases is normal. Unstable is exactly what we want to hear about and fix.
[20:48] <tdonohue> mhwood +1 (also we have Bamboo to help catch the bigger instability problems -- and ensure our current, and future, tests aren't failing)
[20:50] <mhwood> The problem, of course, is that people get the idea that DSpace is flaky. Unfinished code *is* flaky. How to set expectations? How to pick relatively un-flaky revisions from time to time and present them to a wider (but still experimentally-minded) audience?
[20:52] <tdonohue> mhwood -- one way is to actually set "intervals" (from agile development). Essentially, you set "mini-deadlines" before the big ones. So, we could do deadlines for "beta1", "beta2", "RC1", "RC2", "Final" spaced out over a period of time
[20:52] <tdonohue> essentially then, you schedule different features for different "intervals"/deadlines. Features #1 & 2 will be in "beta1", a few more in "beta2", etc
[20:53] * mhwood wonders if some auto-deployer gizmo can be set to watch for new SCM tags in a given branch. We reach agreement that rev. X is fairly stable, tag it, it replaces the previous semi-stable demo.
[20:53] <grahamtriggs> I'll stick my neck on the line - I don't think DVCS makes a huge difference in those terms. It still comes down to a differentiation between code that is shared and code that is local. Sure, having a local versioning of your developments before you share them is useful. Otherwise, a DVCS may be better for synchronizing and branching, but that's really an issue of the quality of the tool, not tied to it's philosop
[20:56] <tdonohue> Well -- sounds like we still have a lot of ideas floating around here :) The general consensus seems to be that we'd like to (1) share code earlier, (2) get feedback/testing earlier, and (3) preferably get that feedback well before RC1, so that a feature has time to morph/change.
[20:56] <mhwood> DVCS can, though, insert a new layer of sharing between unshared and common.
[20:58] <mhwood> tdonohue: sounds that way to me too.
[20:58] <grahamtriggs> mhwood: so can SVN - it's called a branch. But merging and synchronizing code in svn is more complicated than would make it truly useful
[20:59] <tdonohue> Is there any other feedback on this? Obviously, we need to figure out the best way to *accomplish* these goals (several ideas already came up: one or more betas, DVCS, agile practices). We'll keep thinking about this / discussing it so we can figure out what we want to try for 1.8
[21:00] <mhwood> Technology can help, but in the end, getting code out early/often is something that developers do. I need to get better at that.
[21:00] <tdonohue> agreed mhwood :) me too!
[21:01] <tdonohue> I'd also remind everyone that already we do have places to share early/incomplete code in our SVN. Mainly in both the 'modules' and 'sandbox' areas.
[21:02] <tdonohue> modules: http://scm.dspace.org/svn/repo/modules/ and sandbox: http://scm.dspace.org/svn/repo/sandbox/
[21:02] <tdonohue> (I know those aren't always the most ideal ways to share code earlier -- but, wanted to remind everyone of them)
[21:03] <mhwood> It's what we have for now and I think we should start by making the best use of what we have. Things like DVCS are another topic, though perhaps with applications to this one.
[21:04] <mhwood> Once we have the conventions and habits established, we can talk about technology to support them better.
[21:05] <tdonohue> One last topic/announcement: 1.7.1 & 1.8.0. We still need one or more volunteers to be the 1.7.1 and/or 1.8.0 Release Coordinator! So, if you are interested (or potentially interested), let me know. (I'm anticipating we'll probably have a 1.7.1, since we've never not had an X.X.1 release)
[21:06] <richardrodgers> On which point, have we heard of any real 1.7.0 nasties yet?
[21:06] <tdonohue> not to my knowledge. The worst I've heard is that 1.7.0 actually needs Maven 2.2.x or above to build (the docs actually wrongly said 2.0.8 or above)
[21:07] <tdonohue> Anyone try a 1.7.0 upgrade locally yet, or notice anything else?
[21:09] <tdonohue> ..i'll take that as a "No, Tim, we haven't started our upgrade yet" :)
[21:10] <vhollister> Univ of Mich is working on their upgrade -- don't know any details or issues -- plan to have it up before the end of Jan
[21:11] <tdonohue> Ok -- we're running quite a bit over now. So, we can close things up. Let me know if you are interested in being the next Release Coordinator (or even co-Coordinator)! Also, let Val or I know if/when you are upgraded to 1.7 (or know of someone). We want to announce/highlight some of the earlier adopters
[21:11] <tdonohue> thanks vhollister!
[21:11] <mhwood> We'd like to try the new Mirage theme as a basis for upgrading a repo. from 1.5.x, but it's still just planning.
[21:12] <hpottinger> University of MO plans to start process end of January, deploy by end of March
[21:12] <tdonohue> hpottinger: excellent! definitely let us know how it goes
[21:13] * tdonohue consider meeting adjourned. though as always, you are welcome to hang out for a while (i will)
[21:13] <grahamtriggs> I've been working on a 1.6 / 1.7 upgrade since before 1.7 was released. However, now, I need to get Freemarker running.....
[21:13] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[21:13] <tdonohue> grahamtriggs -- well, let us know if you all get anyone running 1.7 soon
[21:14] <tdonohue> look at that, it's mdiggory :)
[21:14] <hpottinger> tdonohue: any ideas on time frame for next release? We're assuming the same 6 months, until we hear otherwise
[21:14] <mdiggory> did I get the wrong time here?
[21:14] <tdonohue> mdiggory -- yea, meeting is at 20:00UTC, which is 75 minutes ago. we're just closing up
[21:15] <mdiggory> anyone using the dspace google calendar for scheduling?
[21:15] <tdonohue> hpottinger: for 1.8.0? Unsure yet. The time between 1.6.0 and 1.7.0 was actually *9* months. But, that's still up for discussion
[21:15] <richardrodgers> gotta go - thanks all
[21:15] * ksclarke (~kevin@adsl-235-136-109.clt.bellsouth.net) Quit (Ping timeout: 255 seconds)
[21:15] * richardrodgers (~richardro@dhcp-18-111-15-218.dyn.mit.edu) Quit (Quit: richardrodgers)
[21:16] <tdonohue> mdiggory -- yea, I am. I use it all the time. It should have the correct time on it, as I switched all the times after daylight savings change
[21:16] <mdiggory> currently says 1pm PST
[21:17] <tdonohue> not mine -- I see it saying "2pm CT" = "noon PT"
[21:17] <mdiggory> are we referring to http://www.google.com/calendar/embed?src=3mfp5qsv0kejvsbh558lmshujk%40group.calendar.google.com&ctz=America/Los_Angeles
[21:17] <tdonohue> which one are you using? There's a DuraSpace Public Events calendar, which has the correct days/times for both DSpace & Fedora mtgs
[21:18] <mdiggory> I'm sure you guys created a new one I guess
[21:18] <tdonohue> nope.. that's not the correct one
[21:18] <tdonohue> let me find the URL for the DuraSpace one
[21:19] <tdonohue> https://www.google.com/calendar/hosted/fedora-commons.org/embed?src=fedora-commons.org_o5iransoopr4i05f7ajpkab7ms@group.calendar.google.com&ctz=America/Chicago&gsessionid=OK
[21:19] <mhwood> mdiggory referred us to the "DSpace Community" calendar. I have it linked to my Google Calendar page but don't visit Google Calendar often enough.
[21:19] <hpottinger> tdonohue: oops, 9 not 6, felt like 6 :-) ok, we'll assume 9 until we hear otherwise
[21:21] <tdonohue> The new DuraSpace Public Events calendar is linked above. So, that old DSpace Community calendar is now out-of-date (and you should replace it if you use it, as it's unmaintained)
[21:22] <tdonohue> hpottinger: yea. It's still up for discussion, but I'd imagine that 1.8 would likely be a similar schedule, and within 9-12mos after 1.7.0. But, once a final decision is made, we'll announce it on the lists
[21:23] <mdiggory> Yes, I'll kill that old calendar and start using tdonohue's
[21:24] <tdonohue> mdiggory: sorry for the confusion :) I actually forgot there used to be a DSpace Community calendar. That one has likely been unmaintained for a while..
[21:24] <hpottinger> todonohue: our dev schedule is based on an iteration every 3 months, so we'll still be able to sync up with whatever the DSpace release is, as long as we're talking multiples of 3 :-)
[21:25] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Quit: Page closed)
[21:27] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) Quit (Quit: Page closed)
[21:28] <sandsfish> gotta run, by all.
[21:28] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[21:28] * sandsfish (~sandsfish@75-138-180-114.dhcp.oxfr.ma.charter.com) Quit (Quit: sandsfish)
[21:29] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:37] * ksclarke (~kevin@adsl-235-136-109.clt.bellsouth.net) has joined #duraspace
[21:47] <mhwood> For anyone else as un-hip as I: to add the DuraSpace calendar to your own Google Calendar, you can log onto Google, go to the DS calendar page (above), poke the "+Google" button in the lower right corner, and you'll be asked if you want to add it to your own calendar. I suppose that's documented somewhere....
[22:01] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[22:04] <tdonohue> All - I also added links to the DuraSpace Public Calendar in the top section of our Meetings page (includes a link to iCal, if you use a different calendar system): https://wiki.duraspace.org/display/DSPACE/Developer+Meetings
[22:07] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[22:08] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[22:09] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Remote host closed the connection)
[22:14] * hghgh (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[22:15] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[22:16] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[22:16] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Client Quit)
[22:17] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[22:24] * PeterDietz (~PeterDiet@128.146.175.194) Quit (Quit: shutdown)
[22:26] * hghgh (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[23:07] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.