Timestamps are in GMT/BST.
[2:01] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[2:11] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[2:16] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[2:16] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[2:16] * bradmc__ is now known as bradmc
[2:19] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[2:19] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[2:19] * bradmc__ is now known as bradmc
[3:01] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[3:04] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[3:05] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Client Quit)
[6:38] -wolfe.freenode.net- *** Looking up your hostname...
[6:38] -wolfe.freenode.net- *** Checking Ident
[6:38] -wolfe.freenode.net- *** Found your hostname
[6:38] -wolfe.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:25] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[12:57] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:06] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[13:08] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:02] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:32] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[15:43] * bradmc (~bradmc@pool-71-162-98-124.bstnma.east.verizon.net) has joined #duraspace
[18:30] * bradmc (~bradmc@pool-71-162-98-124.bstnma.east.verizon.net) Quit (Quit: bradmc)
[19:06] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:53] * bradmc (~bradmc@pool-71-162-98-124.bstnma.east.verizon.net) has joined #duraspace
[19:54] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:54] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:00] <tdonohue> Welcome all, here's the agenda for today's DSpace Developer mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-15
[20:00] <kompewter> [ DevMtg 2012-02-15 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-15
[20:00] <tdonohue> As usual, we'll "warm up" with some JIRA reviews today. https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-946+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-946 ] - [#DS-946] index-update not updating author browse index - DuraSpace JIRA
[20:00] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-946+ORDER+BY+key+ASC
[20:00] <tdonohue> starting with DS-946
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-946 ] - [#DS-946] index-update not updating author browse index - DuraSpace JIRA
[20:02] <tdonohue> this one is a verified bug (see comments) which still exists on Trunk. Mainly just needs a volunteer to investigate it
[20:02] <mdiggory> browse or discovery?
[20:02] <mdiggory> they say they enabled discovery
[20:02] <KevinVdV> Well I think they are refering to the default DSpace browse
[20:02] <tdonohue> I know traditional browse has this bug. Not sure about discovery
[20:04] <mdiggory> maybe they should verify that its just browse by replicating it without discovery enabled.
[20:04] <KevinVdV> Discovert shouldn't have this issue, the reason being when an item is deleted from the index there is no way to unindex it in the current browse implementation (correct me if I'm wrong)
[20:04] <mdiggory> the bug still exists in trunk?
[20:04] <tdonohue> mdiggory: I already verified that. I tried it without discovery (see the final comment). It exist on Trunk with Discovery disabled
[20:04] <mdiggory> k
[20:05] <mdiggory> it should be deleted from browse index as well.
[20:05] <mdiggory> This was something that still remained "hardwired"
[20:05] <KevinVdV> Yes but @ the moment their is no link between a browse author & the item it belongs to
[20:05] <mdiggory> hardwired in Item itself
[20:05] <tdonohue> anyone care to investigate this? I think we just need someone to figure out what the underlying issue is and how best to resolve it
[20:06] <mdiggory> IE, all the browse add/update code was moved to a consumer, but because of an fkey constraint on the db, the delete had to remain in the Item.delete method
[20:06] <mdiggory> it was a design failure of the Event system
[20:07] <mdiggory> or of Browse itself...
[20:07] <tdonohue> hearing no volunteers to investigate?
[20:08] <tdonohue> ok. Ds-946 summary: Bug has been verified. Still needs a volunteer to investigate underlying cause & find a fix
[20:09] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Item.java#L1955
[20:09] <kompewter> [ dspace-api/src/main/java/org/dspace/content/Item.java at master from DSpace/DSpace - GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Item.java#L1955
[20:09] <mdiggory> My favorite part of this comment...
[20:09] <mdiggory> * Any fix would involve too much work on Browse code that
[20:09] <mdiggory> ** is likely to be replaced soon anyway. --lcs, Aug 2006
[20:10] <tdonohue> mdiggory: that seems to imply it should be removing itself from the Browse Indexes -- but, the truth is that isn't happening. It only removes itself from Browse By Title. It never gets removed from Browse By Author/Subject
[20:11] <KevinVdV> tdonohue: t.b.h. how could it ? the entries in the browse by author/subject table retain no links to the item, am I right ?
[20:12] <KevinVdV> I may me wrong (not THAT familiar with the browse system)
[20:13] <tdonohue> I don't know to be honest. I'm not that familiar with everything in browse system either. It just seems wrong to leave empty authors/subjects around that never seem to get cleaned up properly
[20:13] <tdonohue> I think the key thing here is we just need someone to dig in deeper here. Hopefully we can find someone to volunteer for Ds-946 offline
[20:14] <tdonohue> ok, i'm going to move on...feel like we're just spinning our wheels on Ds-946
[20:14] <tdonohue> next up, DS-949
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-949 ] - [#DS-949] Curation needs to document queueing with workflow configuration - DuraSpace JIRA
[20:15] <hpottinger> My plate's pretty full, but this kind of bug (946) bothers me, I'll claim it if no one beats me to it.
[20:15] <tdonohue> oh, this is about documentation. we may just want to ask richardrodgers about Ds-949, as he did those docs initially
[20:15] <tdonohue> hpottinger: feel free to claim it if you want :)
[20:16] <tdonohue> Ds-949 summary: Tim will contact richardrodgers about this
[20:16] <mdiggory> not only this, it needs to be ported to Configurable Workflow as well.
[20:17] <tdonohue> mdiggory: sounds like we should open that as a separate ticket
[20:17] <mdiggory> yes
[20:18] <tdonohue> ok. we'll stop the JIRA review there for today.. on to discussion topics!
[20:19] <tdonohue> first up, 1.8.2 updates. Reminder that any 1.8.2 fixes should be committed to the 1.8.x branch before end-of-day on Monday (Feb 20)
[20:20] <tdonohue> For 1.8.2, I had one ticket specifically that I'd like feedback on, as I'm not clear how the "bitstream reordering" is actually supposed to work: DS-1122
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1122 ] - [#DS-1122] When adding a Bitstream to a Bundle, the 'bitstream_order' is always set to the 'sequence_id' - DuraSpace JIRA
[20:21] <tdonohue> One related issue is that after a new Item Submission, all bitstreams currently start out in a random order (they all are assigned "bitstream_order=-1" by default)
[20:21] <tdonohue> I had also emailed dspace-devel about this, but didn't get any response. Not sure if anyone here knows how this should function, and whether there is a bug here or not?
[20:22] <tdonohue> http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg08375.html
[20:22] <kompewter> [ [Dspace-devel] Bitstream ordering always initialized to -1 (unordered)? ] - http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg08375.html
[20:22] <KevinVdV> Well it is a bug the numbers of the bitstreams should always be the ones in the order they have been added (for new ones that is)
[20:22] <mdiggory> So you preserve Bitstream order in the AIP?
[20:23] <tdonohue> nope, I currently cannot preserve bitstream order in the AIPs. I'd like to preserve it, but currently it's impossible as any new Item added to DSpace (via AIP or via Submission UI) always resets all bitstreams to "order=-1"
[20:24] <mdiggory> ordering was never a full feature in dspace.
[20:26] <mdiggory> I'm trying to remember my past position on ordering being in Bundle
[20:26] <tdonohue> ok. maybe that's my confusion. I just don't know how this is supposed to work. The current implementation though makes it impossible to retain ordering in an AIP (In reality, AIPs already retain bitstream ordering, it's just that DSpace cannot restore it)
[20:26] <KevinVdV> The bitstream order should be set in the order the bitstreams are added to the item
[20:26] <mhwood> Isn't this one of those places where order was thought to be insignificant, and then we heard from the user community that it most definitely is significant?
[20:27] <mdiggory> Order in the UI you mean
[20:27] <mdiggory> speaking to mhwood
[20:27] <mhwood> Yes, in the UI.
[20:28] <tdonohue> I've found the underlying problem here...the underlying issue is that "Bundle.addBitstream()" tries to set the proper order on a new bitstream. But, unfortunately, it uses "sequence_id" to set the ordering, and "sequence_id" is uninitialized (-1) until Item.update() gets called.
[20:28] <mdiggory> Thus the question is, if ordering is an intrisic part of the DSpace API itself, or just behavior on it
[20:28] <mhwood> Anyway, you get different answers depending on whether you think "how it's supposed to work" means "how was it designed" or "how is it used?"
[20:29] <mdiggory> ordering was a customization after the design.
[20:29] <mdiggory> but... not to distract...
[20:30] <mdiggory> tdonohue: sounds like we need a method that includes the ability to pass the order?
[20:30] <tdonohue> my understanding is that folks really wanted/like this feature (like mhwood remembers). It also would make sense that if you do a backup & restore (via AIPs or otherwise), you'd expect things to get restored with bitstreams in the same ordering.
[20:30] <tdonohue> mdiggory: yea, that might be a possible fix. I was wanting feedback from others though, as I wasn't sure if I fully understood how this is supposed to work (hence my questions)
[20:31] <mdiggory> If order / position were a property of the Bitstream, then you;d have something concrete to preserve and restore, reguardless of the logic for things getting added to a bundle
[20:32] <mdiggory> right now ordering is controlled in Bundle but based on properties of bitstream
[20:32] <mdiggory> String bitstreamOrderingField = ConfigurationManager.getProperty("webui.bitstream.order.field");
[20:32] <mdiggory> String bitstreamOrderingDirection = ConfigurationManager.getProperty("webui.bitstream.order.direction");
[20:34] <mdiggory> note these are fields in
[20:34] <mdiggory> bitstream.*,bundle2bitstream.bitstream_order
[20:34] <mdiggory> so ordering is derived from either the Bitstream fields or the bundle2bitstream.bitstream_order field
[20:35] <mdiggory> so this case is only in regards to when its set in bundle2bitstream.bitstream_order
[20:35] <tdonohue> right, mdiggory. And when you set: 'webui.bitstream.order.field=bistream_order', that's where the ordering is always initialized to -1 for newly added bitstreams
[20:36] <mhwood> I don't see why this is a concern of either Bitstream *or* Bundle. It seems to me it belongs to Item.
[20:36] <mdiggory> and thats because the sequence isn't producing until a commit happens...
[20:36] <tdonohue> mhwood: that's a good thought. That's exactly how *sequence_id* is managed, at the item level
[20:38] <tdonohue> which is what causes the oddity here. bitstream_order is managed by Bundle, but it tries to initialize itself via the 'sequence_id' which doesn't get initialized until the Item is updated
[20:39] <mdiggory> that sequence_id comes from?
[20:39] <mdiggory> bitstream_seq;
[20:39] <mdiggory> or bundle2bitstream_seq;\
[20:40] <tdonohue> sequence_id actually doesn't use a DB sequence. It just locates the highest value in the Item and adds one
[20:40] <mdiggory> bundle2bitstream_seq;
[20:40] <tdonohue> so, this is all a mess, to be honest. It's just shown itself in the fact that bitstream_order doesn't work as planned
[20:41] <mdiggory> mappingRow.setColumn("bitstream_order", b.getSequenceID());
[20:41] <mdiggory> comes from the bitstream_seq
[20:41] <tdonohue> ??
[20:42] <mdiggory> just clarifying that I understand now what you said earlier
[20:42] <KevinVdV> Couldn't we just add a bitstream_order on bitstream add to bundle & on each remove from bundle recalculate the order of the bitstreams ?
[20:43] <tdonohue> KevinVdV -- I think so, it's just that in initializing bitstream_order (in add to bundle), you couldn't use 'sequence_id' as it doesn't get initialized until later.
[20:44] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Bundle.java#L456
[20:44] <kompewter> [ dspace-api/src/main/java/org/dspace/content/Bundle.java at master from DSpace/DSpace - GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Bundle.java#L456
[20:44] <tdonohue> I'm wondering if it might make more sense to bring this discussion over to dspace-devel or to JIRA ticket?
[20:44] <KevinVdV> True but you could use bitstreams.size() or something like that IF you recalculate it in removeBitstream each time it should be alright
[20:45] <tdonohue> KevinVdV -- yes, that could work. Just not sure how expensive it'd be to recalculate -- but maybe it wouldn't be that bad overall.
[20:46] <KevinVdV> Well you would just have to recalculate on the bistreams AFTER the current one
[20:46] <KevinVdV> current one == the removed one
[20:46] <tdonohue> In any case, KevinVdV do you want to bring this discussion over to dspace-devel or to Ds-1122? Maybe we can brainstorm out a resolution/fix along those lines.
[20:47] <KevinVdV> I will add this discussion to the JIRA & add my own thoughts below it
[20:47] <mhwood> In case it's relevant, there was some discussion of the meaning and use of sequence_id back on 25-Oct-2011: Message-ID: <20111025175822.GA15444@IUPUI.Edu>
[20:48] <tdonohue> Thanks KevinVdV -- just trying to keep this discussion moving along a bit. I think your ideas sound good, to be honest & I'd be glad to help test them out once we get them into code.
[20:49] <tdonohue> thanks mhwood for tracking that down
[20:49] <tdonohue> ok. Sorry for taking over this meeting a bit around Ds-1122, but I was just a bit confused as to how to proceed. It'd be nice to fix for 1.8.2 obviously, if we can
[20:50] <tdonohue> Anything else folks have that they want to discuss for 1.8.2?
[20:51] <KevinVdV> Just a heads up should anybody else have noticed it but I THINK that the solr in DSpace 1.8 will not run on tomcat 5. I plan to investigate this in the weekend & have a fix ready come monday
[20:52] <tdonohue> ok, thanks for letting us know KevinVdV (hopefully not too many folks are still on Tomcat 5 these days)
[20:52] <tdonohue> sounds like no one else has any 1.8.2 discussions to bring up...so we can move along
[20:52] <mhwood> If that's Tomcat 5.0, the fix for this and hundreds of other problems is to upgrade to a maintained version.
[20:53] <KevinVdV> I had the issue with tomcat 5.5
[20:53] <mhwood> Just wanted to be clear.
[20:53] <KevinVdV> mhwood: ofc
[20:54] <tdonohue> As mentioned via email (and last week's mtg), our first ever Developers Virtual Summit will be Feb 27-Mar 2. Again, the idea is to make this a sort of "unconference". But, if folks have topics they'd like to suggest, feel free to post them to the wiki page.
[20:55] <tdonohue> One thing to note on Virtual Summit. I'm still debating on whether to do this as Google+ or something else (that would allow for more than 10 people at once). I've already heard some excitement brewing from developers (non-committers) and am not sure if it will make 10 person limit a large issue
[20:56] * bradmc (~bradmc@pool-71-162-98-124.bstnma.east.verizon.net) Quit (Quit: bradmc)
[20:56] <tdonohue> but, at the same time, I'm hoping to keep these meetings "manageable", so that we can actually get something done. That gets a bit harder the more people we have in a single meeting.
[20:57] <tdonohue> (so -- willing to entertain feedback, either now or later.)
[20:57] <mdiggory> still not even sure what a Hangout is or how one participates in one... guess I'm uncool...
[20:57] <hpottinger> G+ hangouts can have a spectator-only option, but it's not an option that's available to all Google + users
[20:58] <tdonohue> Google+ Hangout = Googles version of a "Group Video Chat". It's almost like a ChatRoom, where folks can hangout and others show up & leave as they want -- but it's video/audio.
[20:58] <mhwood> You install the Google Voice and Video Plugin, curse when it crashes your browser, hunt down the backlevel libraries it's linked against, find copies somewhere, and try again.
[20:58] <tdonohue> haha ;)
[20:59] <mhwood> I think I have it working, sort of, except that it shows a kind of fly's-eye version of me.
[20:59] <mdiggory> ok, I at least knew that, I just don't use it...
[20:59] <hpottinger> I'm thinking that Skype may be the way to go, if we expect more than 10 participants at a time
[20:59] <tdonohue> ok. well, the question is -- would you all like to try G+ Hangouts? The other option is to just do Skype and I can setup a FreeConferenceCallHD phone # that everyone can call into (either via skype or normal phone line)
[21:00] <mdiggory> I actually prefer the IRC channel because of the logging...
[21:01] <mhwood> Logging +1
[21:01] <tdonohue> The problem with IRC is that I find it difficult to discuss topics in much depth at times. So, I was thinking of this Virtual Summit as more like our normal OR Committers Mtg.
[21:02] <hpottinger> here's the info I can find on "Hangouts On Air" which does produce a record http://support.google.com/plus/bin/answer.py?hl=en&answer=1669903
[21:02] <kompewter> [ Hangouts On Air - Google+ Help ] - http://support.google.com/plus/bin/answer.py?hl=en&answer=1669903
[21:03] <hpottinger> Anyone at DuraSpace have any pull with the Google folks?
[21:03] <tdonohue> no, don't really have any "pull" with Google folks
[21:06] <tdonohue> So, is Skype a "good enough" compromise here? We could always also keep notes via IRC. THis is actually exactly how Fedora does their weekly meetings -- they meet via Skype, but they keep notes publicly in IRC (one person just writes into IRC the gist of what is going on)
[21:06] <tdonohue> just trying to get a sense of where folks heads are at (which is also a difficult thing to gage via IRC)
[21:07] <mdiggory> Skype is ok too
[21:08] <hpottinger> I think the math is unavoidable: if participant.count > 10 then Skype
[21:08] <mhwood> I can do Skype if nobody minds that it may not understand my camera yet. (Test pane just goes black.)
[21:08] <tdonohue> yea, I'm sensing here that folks are not sure about G+ hangouts yet. The 10 person limit also could mean that a few folks would get booted from a particular mtg (if >10 showed up that day)
[21:09] <tdonohue> if we did Skype it'd be audio only. I don't have a paid Skype account (which is what you need for Skype Video Chat). Plus Skype Video has the same 10 person limit
[21:09] <tdonohue> err, I mean I'd need a paid account to do Skype *Group* Video Chat.
[21:10] <tdonohue> ok. so, sounds like the consensus is that we may want to just do Skype then, which is fine.
[21:11] <tdonohue> Any other notes/feedback anyone wants to mention on Virtual Summit?
[21:11] * tdonohue realizes we are over time here -- sorry about that. If you have to head out, feel free.
[21:12] <tdonohue> Final Topic is really just an FYI. Obviously it's time to start prep for Google Summer of Code. I've refreshed our "Ideas page" for DSpace. So, it's waiting for potential project ideas!
[21:12] <tdonohue> https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[21:12] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[21:13] <tdonohue> So, if you have any ideas on something that could be a good project, and/or might be willing to mentor such a project, please add it to the list
[21:13] <tdonohue> We still have a long time to brainstorm out these ideas (The application period for mentoring organizations hasn't even started yet). But, I wanted to get started early.
[21:14] <tdonohue> Last year's ideas page is still archived over at: https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas+2011 So, we also should analyze whether there are project ideas there we'd like to run (as many of these ideas didn't happen last year)
[21:15] <kompewter> [ DSpace Summer of Code Ideas 2011 - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas+2011
[21:15] <tdonohue> Ok. That's the end of the agenda for today. I'll stick around here if anyone has anything else they'd like to discuss
[21:16] <tdonohue> but, consider the official meeting "closed". Now starts any "unofficial" discussion that folks want to have
[21:16] <KevinVdV> FYI I added two possible solutions to https://jira.duraspace.org/browse/DS-1122 anybody interested feel free to respond so I can do the programming in the weekend
[21:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1122 ] - [#DS-1122] When adding a Bitstream to a Bundle, the 'bitstream_order' is always set to the 'sequence_id' - DuraSpace JIRA
[21:16] <kompewter> [ [#DS-1122] When adding a Bitstream to a Bundle, the 'bitstream_order' is always set to the 'sequence_id' - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1122
[21:19] <tdonohue> thanks KevinVdV, I'll take a look
[21:23] <KevinVdV> tdonohue I also had a question about the "Virtual summit" wether it is skype or google+ where do we meet ? (or where do you report that you would like to participate that day ?)
[21:26] <tdonohue> KevinVdV: essentially you just "show up" on days that you can. There's no 'signup' and no formal agenda (it'll be like an unconference -- those in attendance decide what topic(s) to cover that day). As for "where" we meet....
[21:26] <tdonohue> since it sounds like we'll meet via Skype, I'll setup a phone# that you can call into (via either Skype or your landline). It'll just be essentially a "conference call"
[21:27] <tdonohue> (If we had decided to meet via G+, then essentially I'd just startup a "Hangout", which is like a video ChatRoom, and you'd just login & join that Hangout)
[21:28] <hpottinger> to clarify a bit with G+, you'd sign in to G+ and you'd see a note that people are "hanging out" or "started a hangout" in your stream, then you just click to join the hangout (assuming you have the hangout software already installed)
[21:30] <hpottinger> jumping topics a bit, one of our librarians just forwarded a link to https://github.com/ORCID/ORCID-Mock-API-Web-Application
[21:30] <kompewter> [ ORCID/ORCID-Mock-API-Web-Application - GitHub ] - https://github.com/ORCID/ORCID-Mock-API-Web-Application
[21:30] <mhwood> How does G+ know that I care someone is hanging out somewhere? I guess I would need a bunch of contacts.
[21:31] <hpottinger> mhwood, it's up to the person who starts the hangout to select what "circle" or "circles" to which to broadcast the invitation to hang out
[21:31] <tdonohue> mhwood -- yea, you only see "hangouts" for your contacts. So, if we did the G+ Hangout, you'd have to add me as a contact, or I'd have to make the hangout "public" and send you a link to it.
[21:33] <KevinVdV> *Adds tdonohue to a circle just in case*
[21:33] <hpottinger> for the record, I'm hardy.pottinger AT gmail in the G+ world, if you haven't already circled me
[21:34] <tdonohue> & I'm tim.donohue
[21:35] <KevinVdV> *adds hpottinger*
[21:35] <mhwood> mwoodiupui at gmail
[21:36] <hpottinger> circled the lot of ya
[21:36] <mhwood> But I'm hardly ever there (or facebook, or....)
[21:37] <KevinVdV> kevin.van.de.velde at gmail
[21:44] <KevinVdV> Need to run guys, until next time
[21:45] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: KevinVdV)
[22:05] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[22:34] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[23:11] * tdonohue (~tdonohue@c-67-177-108-221.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.