Timestamps are in GMT/BST.
[1:21] * kdweeks (~Adium@2001:468:c80:a103:993f:ce79:b616:83f1) Quit (Quit: Leaving.)
[6:31] -orwell.freenode.net- *** Looking up your hostname...
[6:31] -orwell.freenode.net- *** Checking Ident
[6:31] -orwell.freenode.net- *** Found your hostname
[6:32] -orwell.freenode.net- *** No Ident response
[6:32] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:32] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:32] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:32] -orwell.freenode.net- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[12:26] * pbecker (8295b1d6@gateway/web/freenode/ip.130.149.177.214) has joined #duraspace
[12:26] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:31] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[14:06] * bram-atmire (~bram@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:13] * kdweeks (~Adium@2001:468:c80:a103:d950:342f:b239:ed7f) has joined #duraspace
[14:57] * Anja (82587893@gateway/web/freenode/ip.130.88.120.147) has joined #duraspace
[15:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting (this time at 15 UTC!). Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-05-21
[15:01] <kompewter> [ DevMtg 2014-05-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-05-21
[15:02] <tdonohue> Good to see a few Europeans joining us today.... I was hoping we'd get a more diverse crowd at this time :)
[15:02] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[15:02] <tdonohue> We'll kick things off today with just a few notes/announcements/reminders....
[15:02] <bram-atmire> thanks for accomodating this timeslot
[15:02] <pbecker> yes, that's great.
[15:02] * hpottinger can't believe he made it :-)
[15:03] <tdonohue> no problem! The only reason I even delayed that decision on a new timeslot was that I didn't get any real feedback when I initially made the suggestion ;) But, It's good to see it's worked out already
[15:04] <tdonohue> in any case...a few notes. If you are going to OR14, we'd love to have you join our Developer Face-to-face meeting on that Monday. Please signup at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting if you are interested
[15:04] <kompewter> [ DevMtg 2014-06-09 - OR14 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[15:05] <tdonohue> In addition, mostly for Committers -- we're still looking for a few more DSpace 5.0 Release Team members. If you have any interest, please get in touch. Obviously, we need Release Team members to help us package up & put out another solid release
[15:05] <hpottinger> It's easy and fun, you know you want to!
[15:06] <bram-atmire> Is membership of the release team limited to committers?
[15:06] <tdonohue> Being a Release Team member really isn't hard (as hpottinger can attest)...and it is something you can put on your resume/CV
[15:07] <tdonohue> bram-atmire: Good Question. I'd be open to the idea of having a Release Team member who is not a Committer...but the Committers would likely need to approve of it, as they'd be working with him/her in getting the Release ready
[15:08] <mhwood> As a practical matter, the RT needs at least one committer to make the files go where they belong.
[15:08] <hpottinger> mhwood: 'tis the easiest and most-fun part :-)
[15:08] <tdonohue> yes, mhwood is correct. There will need to be *at least one committer* on the RT...as only a Committer can actually perform/cut the release (as it requires commit rights)
[15:09] <bram-atmire> Right
[15:09] <tdonohue> But, many of the organization/management details performed by the Release Team need not be a Committer. Just needs someone willing to work with the Committers and other Release Team members to organize/schedule the release
[15:10] <tdonohue> Ideally, we'd have 3-6 people on the 5.0 Release Team (as that ensures they can share roles and no single person has to do too much of the organization/mgmt duties). Currently we have 1 volunteer. So, we need some more people on the team to help chip in.
[15:11] <tdonohue> s/share/distribute/
[15:11] <kompewter> tdonohue meant to say: Ideally, we'd have 3-6 people on the 5.0 Release Team (as that ensures they can distribute roles and no single person has to do too much of the organization/mgmt duties). Currently we have 1 volunteer. So, we need some more people on the team to help chip in.
[15:11] <hpottinger> I don't think it would be a big problem to have non-committer on the RT, and it would be an easy problem to overcome if it *did* turn into a problem (but I'm most certainly not making any promises in that regard)
[15:11] <tdonohue> hpottinger ++
[15:12] <tdonohue> In general, I suspect no one would object to having a non-committer on the RT. But, I'd just want to run it by the Committers to be certain.
[15:12] <mhwood> I don't see a problem with the RT bringing in anyone who can do the work well.
[15:13] <hpottinger> do we have enough people to vote?
[15:13] <bram-atmire> just trying to think if this is a way of contributing that would work for some of our more junior developers
[15:13] <bram-atmire> but they can do things like reviewing pull requests, documentation or doing new pull requests without being on the release team
[15:13] <bram-atmire> so it’s not really an issue
[15:14] <hpottinger> bram-atmire: agreed, the entire community can and should be doing those things
[15:14] <bram-atmire> it would also be really lovely if specific members of the community/release team could step up to assume responsibility for a certain functional area
[15:15] <bram-atmire> for example, some one who focuses on JSPUI-only contributions / evaluating pull requests
[15:15] <bram-atmire> someone who does the same for XMLUI
[15:15] <hpottinger> ah, if only there were more than one RT member... alas...
[15:15] <bram-atmire> SWORD, OAI-PMH, performance, ...
[15:15] <bram-atmire> well
[15:15] <tdonohue> bram-atmire: nice idea. I like that concept of taking charge of certain "functional areas"
[15:16] <bram-atmire> even if we’re not in the release team, we may want to do something like this for XMLUI as part of the Mirage 2 contribution
[15:16] <bram-atmire> I mean clearly: if mirage 2 would make it into the core, we wouldn’t want to see it break because of some other contribution
[15:17] <tdonohue> All the more reason to try and get Mirage 2 in *early* (so that other contributions can take it into account) :)
[15:17] <tdonohue> (if possible, that is)
[15:18] <hpottinger> +1 early contributions
[15:18] <bram-atmire> right, we’re still having the debate internally on what that may look like. Here’s the opportunity which also presents a challenge:
[15:18] <hpottinger> especially big infrastructure changes, earlier the better
[15:19] <bram-atmire> the “developer build” for mirage 2 relies on a few new tools and build process steps. (SASS/LESS, grunt, …)
[15:20] <bram-atmire> pushing this into the core would mean that the building and compilation would become a bit more complicated because of the required tools
[15:21] <bram-atmire> but if we would only contribute the “compiled” version which does not contain the dependencies on these build tools, the possiblities for a developer to use all of the nice tools to do customizations
[15:21] <hpottinger> this brings up a slightly-related thing I'd like to discuss at some point, do we need to clear a space for "helpful scripts or files" in DSpace build? I'm thinking about the RHEL-specific init script I just cobbled together, since there's no adequate version of Tomcat available for RHEL6
[15:21] <bram-atmire> anyway, both the source version and precompiled version are already up for download here:
[15:21] <bram-atmire> https://atmire.com/website/?q=download-mirage-2
[15:21] <kompewter> [ Download Mirage 2 Beta 1 | atmire ] - https://atmire.com/website/?q=download-mirage-2
[15:21] <bram-atmire> as well as documentation
[15:22] <bram-atmire> so any feedback would be welcome or ideas on what the “optimal” approach would be
[15:22] <tdonohue> Is it possible to ship the "compiled version" but have guides for how to modify it via SASS, etc. I'm still unclear on the limitations of the "compiled version" vs. the "developer build"
[15:22] <tdonohue> (admittedly, I haven't had time to pull down Mirage 2 myself...but it's not clear what can be done in the "compiled version" vs. developer build)
[15:23] <bram-atmire> simple example: some colour is defined as a sass variable and other colours are derived from it
[15:23] <bram-atmire> so changing this colour in sass would be a simple, one-variable change
[15:23] <bram-atmire> but you can also start tweaking the colours in the compiled css files
[15:23] <bram-atmire> which would have you make more changes in different places
[15:24] <tdonohue> Current Mirage also requires you to tweak colors in many places in the CSS, so that sounds no different
[15:24] <bram-atmire> some institutions have already been putting the beta in production, for examples here: http://www.tara.tcd.ie/
[15:24] <kompewter> [ TARA ] - http://www.tara.tcd.ie/
[15:24] <bram-atmire> you’re right tim: it would definitely not be WORSE than the old mirage
[15:24] <bram-atmire> but the advantages would be smaller
[15:25] <bram-atmire> but i’m a bit out of my league here, since this discussions about this are currently still very much on the table
[15:25] <tdonohue> I'm trying to get a realistic view on what institutions will *want* to do with Mirage 2. Are 80-90% just going to tweak the color scheme in the CSS (in which case "compiled version" sounds best), are are there really going to be many folks who want to mess with SASS, etc. I'd lean towards the "former"
[15:26] <tdonohue> i.e. if *most people* really are just going to tweak CSS anyways, then why force them to use SASS, etc...just ship the "compiled version", and provide tools/guides for those who want to re-compile it
[15:26] <hpottinger> the nice thing about the SASS toolchain is that it can be shared across projects (DSpace, Drupal, etc.)
[15:27] <mhwood> Nothing leaps out at me as being terribly complex about running some source generators, attached to the appropriate Maven phase(s).
[15:28] <bram-atmire> valid questions, I think we’ll need to put together a few usecases/examples to clarify
[15:28] <tdonohue> mhwood: the complexity is that in order to *compile* Mirage 2, you need to install extra dependencies...things like Ruby and Node.js. I'd rather avoid forcing *everyone* to add even more dependencies in order to actually install Dspace
[15:28] <mhwood> Ah.
[15:29] <tdonohue> In my opinion, putting everyone through the process of Compiling Mirage 2 is a "complete no-go". There's no reason to require everyone install Ruby or Node.js to install DSpace...as nothing else in DSpace depends on those tools
[15:29] <hpottinger> You can actually automate almost all of the SASS/Grunt stuff, so it's almost invisible to you (you change one file, the changes ripple out to the other files), it's a nice way to work. The stuff required to make Mirage 2 go is stuff we'd really like to be using across all of our web development projects, I'd be happy for DSpace to lead the way
[15:30] <mhwood> It's another github project, then, with output that's a dependency of DSpace/DSpace. You can rebuild it if you want to.
[15:31] <tdonohue> mhwood++ Good idea. That might be the best route. Think of splitting XMLUI source code into its own separate GitHub project...and the pre-compiled version gets pulled into DSpace/DSpace (via mvn)
[15:32] <hpottinger> hmm... Git submodules, cool
[15:33] <tdonohue> hpottinger: I actually wasn't suggesting Git Submodules...but it's possible, I guess. I was just saying a project named "DSpace/dspace-mirage2" (source of Mirage 2) gets compiled & released to Maven Central...and it's then a dependency of "Dspace/Dspace"
[15:34] <tdonohue> That way, users who want to *recompile* Mirage 2 can just checkout/clone "DSpace/dspace-mirage2" and rebuild it as they see fit.
[15:34] <tdonohue> But, most everyone else would just get the pre-compiled version that gets pulled in (from Maven Central) when they install DSpace
[15:34] <pbecker> This seems to me as a perfrect solution, if it is well documented.
[15:35] <tdonohue> yep, definitely needs to be well documented ;)
[15:36] <tdonohue> bram-atmire: does that give you enough feedback to go on, regarding Mirage 2?
[15:36] <mhwood> Getting the Mirage 2 source conditionally included in the reactor will be interesting. We may need Yet Another Profile. Not something I understand well.
[15:36] <bram-atmire> thanks, will definitely report back on your feedback
[15:37] <tdonohue> mhwood: yea, "tying things together" via Maven is sometimes a bit of a challenge...but, it should be doable. Just needs someone to sit down and dig in -- probably another reason though to try and get something started *EARLY*
[15:38] <tdonohue> So, we've gone a bit off the agenda here, but I think it was an important discussion. I, personally, am excited to see Mirage 2 get into DSpace 5. We just need to be careful to not complicate our current installation process
[15:39] <hpottinger> I'm OK with keeping the simple version simple, as long as it doesn't raise the bar too high on the awesome version :-)
[15:40] <tdonohue> hpottinger: yes, I understand. The reality here though is that we need to remember that (probably) all of us here are "advanced users" and 80-90% of the other DSpace Users are not going to need or want the "awesome version" :)
[15:41] <tdonohue> In any case, the agenda today is a bit light...so no big deal that we sidetracked to talk about Mirage 2.
[15:41] <tdonohue> But, I did want to touch back on the upcoming bug fix releases & their status.... 3.3 and 4.2
[15:42] <tdonohue> 3.3 in JIRA: https://jira.duraspace.org/browse/DS/fixforversion/11841
[15:42] <kompewter> [ DSpace: 3.3 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11841
[15:42] <tdonohue> 4.2 in JIRA: https://jira.duraspace.org/browse/DS/fixforversion/11840
[15:42] <kompewter> [ DSpace: 4.2 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/11840
[15:42] <hpottinger> for 4.2, I still haven't had a chance to test the fix for DS-1906, am hoping to get to it today
[15:42] <kompewter> [ https://jira.duraspace.org/browse/DS-1906 ] - [DS-1906] Shibboleth attributes may need to be reconverted - DuraSpace JIRA
[15:43] <tdonohue> 4.2 still looks to have a lot of open, unresolved issues (13 of them). 3.3 is closer...just 3 unresolved issues
[15:45] <pbecker> hpottinger: 1906 even is not in the list, as the fix version is not set.
[15:45] <mhwood> One of the 3.3 issues is from me. Nobody's commented. I can just do it.
[15:45] <tdonohue> which ticket is that one?
[15:45] <hpottinger> pbecker, thanks for that catch
[15:46] <mhwood> 1961
[15:46] <tdonohue> DS-1961 sounds reasonable. Just needs a PR & some testing to ensure we don't break any part of the build or install process
[15:46] <kompewter> [ https://jira.duraspace.org/browse/DS-1961 ] - [DS-1961] Use HTTPS with oss.sonatype.org repository - DuraSpace JIRA
[15:47] <hpottinger> 1906 set for 4.2 now, I better get to work, eh? :-)
[15:47] <tdonohue> The other tickets scheduled for 3.3: DS-1998 and DS-1958 both sound like "obvious fixes" and have +1's...so they look to just need merger
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-1998 ] - [DS-1998] "dspace classpath" CLI command does nothing, throws error - DuraSpace JIRA
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-1958 ] - [DS-1958] Discovery OutOfMemoryError when indexing Large Bitstreams. - DuraSpace JIRA
[15:47] <mhwood> Yes, I've been pulled away from DSpace of late. Time to refocus and get this out.
[15:47] <bram-atmire> sorry folks, got to go, byebye
[15:48] <tdonohue> So, 3.3, in my opinion sounds like it's nearly ready-to-go... Are you still able to take the lead on 3.3 then, mhwood?
[15:48] * bram-atmire (~bram@85.234.195.109.static.edpnet.net) Quit (Quit: bram-atmire)
[15:48] <pbecker> hpottinger: take your time. ;-)
[15:48] <mhwood> Yes, will do.
[15:48] <tdonohue> I'll add a +1 to 1998 and 1958. Both seem reasonable. We should just push the green button on each
[15:49] <tdonohue> (and then 'cherry-pick' over to any necessary branches, obviously)
[15:51] * hpottinger wanders off for a sec, brb
[15:51] <tdonohue> I've officially added a +1 to both 1998 and 1958 in JIRA. The only reason I haven't pressed the button is that I don't have my devel environment spun up to do the "cherry-picking"
[15:54] <hpottinger> back
[15:54] <tdonohue> Skimming through the 4.2 tickets...a bunch of these seem "stalled" and may need rescheduling to 5.0. There's a few assigned to abollini or helix84 asking for status (and no response ever came back)
[15:56] <tdonohue> But, I see a few 4.2 tickets still needing volunteers (some have PRs): DS-1929 , DS-1995 , DS-1805 (has PR)
[15:56] <kompewter> [ https://jira.duraspace.org/browse/DS-1929 ] - [DS-1929] editing bitstream description changes bitstream resourcepolicies - DuraSpace JIRA
[15:56] <kompewter> [ https://jira.duraspace.org/browse/DS-1995 ] - [DS-1995] JSPUI Bootstrap dropdowns don't display properly in IE8 or 9 - DuraSpace JIRA
[15:56] <kompewter> [ https://jira.duraspace.org/browse/DS-1805 ] - [DS-1805] Maven filtering broken for SOLR artifact - DuraSpace JIRA
[15:58] <hpottinger> gosh, 1805 looks really easy to confirm
[15:59] <tdonohue> yep, 1805 looks like an "obvious fix"
[15:59] <tdonohue> care to claim it, hpottinger & run a quick test?
[16:00] <hpottinger> I wouldn't want to spoil the fun for anyone else :-)
[16:03] <hpottinger> aw, shoot, I'll take it
[16:03] <tdonohue> Sorry, I was just pulled away for a moment.
[16:03] <tdonohue> Back now though...and I'm realizing we are at the end of our meeting time.
[16:04] <tdonohue> It sounds like 3.3 is nearly ready (just needs final push). 4.2 still seems to need a bit more work...though I suspect many of these tickets could be rescheduled for 5.0 if needed.
[16:05] <tdonohue> Is there anything else we want to quickly touch on today? Or should we wrap up our meeting?
[16:05] <pbecker> I have something, but I'm not sure if this is the time and the place.
[16:06] <pbecker> I was asking myself why a person that submitted items couldn't be deleted?
[16:06] <hpottinger> well, I *think* the Mirage 2 discussion dealt with my question, I just thought I'd re-ask it, would there be interest in providing a space for "extra" scripts/helpful files in the distribution?
[16:06] <pbecker> The information in the item table in the column submitter_id should be in the provenance information as well.
[16:06] * Anja (82587893@gateway/web/freenode/ip.130.88.120.147) Quit (Quit: Page closed)
[16:06] <pbecker> Perhaps it would be better to write a mail to dspace-devel?
[16:07] <mhwood> pbecker: perhaps so.
[16:07] <tdonohue> hpottinger: "extra scripts" probably needs better definition...It "depends". If the Extra Script is going to be "officially maintained/supported" by committers it could go in DSpace GitHub. But, if it's just a local script that you want to share with others, then maybe we just need a better way of helping people find them.
[16:08] <mhwood> But I think this points to a need to separate login credentials from personal details. There has been call for making Submitter, Author, Editor, etc. into repository objects....
[16:09] <hpottinger> I've got a couple of RHEL-specific init scripts for launching Tomcat 6 and Tomcat 7, it's important for running Tomcat 6 and 7 on RHEL since the only supported version of Tomcat and RHEL is 5.5 (cough, sputter)
[16:09] <tdonohue> pbecker: yea, may want to start with an email to dspace-devel. I admit, I'm going to have to step away shortly...I don't have time to discuss this now. But, I agree with mhwood that there may be larger issues here
[16:09] <mhwood> I think there is some work being done on incorporating ORCiD and the like, which would dovetail with this.
[16:09] <pbecker> okay, will do so.
[16:10] <hpottinger> oh, that's an interesting idea: with the ORCID work, do we lose the reason to keep ePerson records forever?
[16:11] <mhwood> What I meant was that this may drive the separation of accounts from persons.
[16:12] <pbecker> hpottinger: that's exactly the problem we have. we must delete ePersons for privacy reasons.
[16:12] <mhwood> So we wouldn't need to keep the *accounts* forever.
[16:12] <mhwood> There would just be EPersons (or derived classes?) that didn't have accounts any longer.
[16:12] <pbecker> our data protection commisioner wants us to delete unused acounts....
[16:13] <hpottinger> pbecker: you could easily drop all group memberships for old eperson records
[16:13] <mhwood> I have no doubt that we will be asked to remove unused accounts at some point, and we should be.
[16:13] <tdonohue> I'm going to close up today's "official meeting" as it sounds like you all are now on a side conversation :) Feel free to continue your discussions -- I just need to step away at this point, and I'll catch back up later on.
[16:14] <mhwood> Thanks tdonohue.
[16:14] <pbecker> hpottinger: the data protection commisioner wants us to delete the accountss completely. It's not a matter of permissions, it's a privacy matter (email address, name, password).
[16:14] <pbecker> and dspace don't want to delete accounts if they submitted any items.
[16:14] <pbecker> so I have to move the submissions to another account or set the sumbitter_id in the item table to null.
[16:15] <mhwood> Yes, because account is tangled up with other identities.
[16:15] <pbecker> I think that shouldn't be a big deal, as the information who submitted an Item should be in the provenance metadata as well.
[16:15] <pbecker> mhwood: what does DSpace needs the submitter_id for?
[16:16] <mhwood> Good question. I'd have to read the code. I suspect that ugly things will happen in the item detail display if an Item has no author. But submitter? I don't know.
[16:17] <pbecker> The author is part of the metadata. I did not had the time to look it up myself, but I will do in the next days.
[16:18] <pbecker> Today I went through all tickets in jira containing the word "submitter", tomorrow I'll look into the code.
[16:18] <pbecker> The submitter is important to show a logged in user his archived submissions.
[16:18] <pbecker> But until now I don't see a reason why every Item needs a submitter.
[16:19] <mhwood> There may be legal reasons why we need to know who submitted an Item. But the provenance record may be sufficient. I need to think about this.
[16:19] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[16:19] <pbecker> Nevertheless, I'll write a mail to dspace-devel as far as I looked into the code.
[16:19] <mhwood> Thank you pbecker.
[16:20] <pbecker> lets keep in touch about that!
[16:21] <mhwood> I think I will have some things to say in the discussion on -devel.
[16:21] <pbecker> I would really appreciate that!
[16:21] <pbecker> Could need help thinking through all of this.
[16:22] <mhwood> I think that several developers will be interested.
[16:22] <pbecker> It's the next thing on my agenda.
[16:22] <pbecker> If you're interessted in this, you may want to look on DS-2012.
[16:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2012 ] - [DS-2012] JSPUI does not write column last_active in database as context is not commited after login - DuraSpace JIRA
[16:23] <pbecker> This is a ticket I filed today, as last_active is not set properly when JSPUI is in use.
[16:23] <mhwood> Thank you. I will look at it.
[16:58] * pbecker (8295b1d6@gateway/web/freenode/ip.130.149.177.214) has left #duraspace
[17:07] * edInCo (~smuxi@seta.coalliance.org) Quit (Remote host closed the connection)
[18:47] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[19:51] * daryl_ (ca4f122e@gateway/web/freenode/ip.202.79.18.46) has joined #duraspace
[20:02] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) has joined #duraspace
[20:02] <robint> Hi all
[20:04] <tdonohue> Hi robint. I hope you aren't here for the Developer Meeting (which happened at 15:00 UTC today...not at 20:00UTC, i.e. nowish)
[20:05] <robint> Just checked the wiki :)
[20:05] <robint> Doh!
[20:06] <robint> I'll pay more attention next week
[20:06] <tdonohue> Yep, I had sent a reminder email to dspace-devel too, but I guess you must've missed it :) http://dspace.2283337.n4.nabble.com/DSpace-Dev-Mtg-Tomorrow-15-00-UTC-and-JIRA-Backlog-Hour-14-00-UTC-td4673163.html
[20:06] <kompewter> [ DSpace - Devel - DSpace Dev Mtg Tomorrow @ 15:00 UTC and JIRA Backlog Hour @ 14:00 UTC ] - http://dspace.2283337.n4.nabble.com/DSpace-Dev-Mtg-Tomorrow-15-00-UTC-and-JIRA-Backlog-Hour-14-00-UTC-td4673163.html
[20:06] <robint> I need to get back in the saddle
[20:07] <robint> Cheers for now
[20:08] <tdonohue> Cheers. Next week, of course it will be at 20 UTC. So, next week, don't show up at 15 UTC ;)
[20:08] <tdonohue> If it gets confusing, there's a weekly calendar (DuraSpace Public Events Calendar) linked off of: https://wiki.duraspace.org/display/DSPACE/Developer+Meetings
[20:08] <kompewter> [ Developer Meetings - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Developer+Meetings
[20:08] <tdonohue> direct link: https://www.google.com/calendar/hosted/fedora-commons.org/embed?src=fedora-commons.org_o5iransoopr4i05f7ajpkab7ms@group.calendar.google.com
[20:08] <kompewter> [ DuraSpace Public Events ] - https://www.google.com/calendar/hosted/fedora-commons.org/embed?src=fedora-commons.org_o5iransoopr4i05f7ajpkab7ms@group.calendar.google.com
[20:13] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) Quit (Quit: Page closed)
[20:26] * daryl_ (ca4f122e@gateway/web/freenode/ip.202.79.18.46) Quit (Quit: Page closed)
[21:06] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Quit: Leaving.)
[21:14] <kshepherd> tdonohue: damn, i tried to show up for this one ;)
[21:14] <kshepherd> tdonohue: i can't make 15 UTC but i will be around for hte next 20 UTC one
[21:15] <tdonohue> yep, I figured as much. Unfortunately there's no "perfect time" for all...Most the Europeans have trouble making 20 UTC, but I realize 15 UTC is the middle of the night for you and aschweer. Hence the rotating schedule.
[21:18] <kshepherd> yeh
[21:18] <kshepherd> i remember seeing it discussed, just didn't occur to me this morning ;)
[22:05] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[22:29] * kdweeks (~Adium@2001:468:c80:a103:d950:342f:b239:ed7f) Quit (Quit: Leaving.)
[22:31] * kdweeks (~Adium@2001:468:c80:a103:d950:342f:b239:ed7f) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.