Timestamps are in GMT/BST.
[0:30] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[1:25] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) Quit (Remote host closed the connection)
[1:25] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[1:30] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) Quit (Ping timeout: 252 seconds)
[6:48] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:48] -rajaniemi.freenode.net- *** Checking Ident
[6:48] -rajaniemi.freenode.net- *** Found your hostname
[6:49] -rajaniemi.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:49] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:49] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:29] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:04] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[15:56] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[16:03] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Ping timeout: 248 seconds)
[16:12] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[17:41] * tdonohue1 (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[17:42] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Ping timeout: 268 seconds)
[17:44] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:01] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:14] * jrgriffiniii (~chatzilla@139.147.64.195) Quit (Read error: Connection reset by peer)
[19:45] * tdonohue1 is now known as tdonohue
[19:57] * kstamatis (b03a994b@gateway/web/freenode/ip.176.58.153.75) has joined #duraspace
[20:00] <tdonohue> Hi all, it's time for the weekly DSpace Developers Meeting. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-10-09
[20:00] <kompewter> [ DevMtg 2013-10-09 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-10-09
[20:01] <helix84> hi kstamatis: you just missed a discussion about citations / CSL / CiteProc / BTE in #dspace
[20:01] <kstamatis> sorry, i couldn't attend
[20:01] <tdonohue> As we've noted in our 4.0 Release Schedule, today is our first day devoted towards New Feature Pull Request reviews
[20:01] <kstamatis> no logs, ha!
[20:02] * bollini (~chatzilla@87.18.60.109) has joined #duraspace
[20:02] <hpottinger> kstamatis, I can forward a transcript to you
[20:02] <tdonohue> Does someone from our Release Team have a listing of the New Feature PRs for us to work from? Just wondering where it's best to start our reviews from today
[20:02] <helix84> hpottinger: I just did
[20:03] <kstamatis> hpottinger: that would be great! Thanks!
[20:03] <kstamatis> helix84: thanks
[20:03] <hpottinger> OK, PRs, bollini came up with a very cool JS thing to organize our PRs, I've put them into a Google Doc
[20:03] <bollini> hpottinger: please send also to me
[20:03] <helix84> http://jsfiddle.net/bollini/C8jcE/2/
[20:03] <kompewter> [ Export github pulls - JSFiddle ] - http://jsfiddle.net/bollini/C8jcE/2/
[20:03] <mhwood> bollini built a tool to extract PRs; hpottinger has been working on a resulting spreadsheet
[20:04] <hpottinger> OK, this is world writable, so you all be on god behavior, hear? :-)
[20:04] <hpottinger> *good*, lol
[20:04] <tdonohue> "god behavior"?
[20:04] * helix84 switches to god mode
[20:04] <hpottinger> https://docs.google.com/spreadsheet/ccc?key=0AimboW73gZRJdEVkdUdxR2Nac0JqeXA1QmRBcmlRbHc#gid=0
[20:05] <hpottinger> it's cold here, I blame these cold fingers
[20:05] <mhwood> "god behavior" = 1/"good behavior": everything you do is right by definition and everyone else has to accept it.
[20:05] <kompewter> [ Google Docs - Online documents, spreadsheets, presentations, surveys, file storage and more ] - https://docs.google.com/spreadsheet/ccc?key=0AimboW73gZRJdEVkdUdxR2Nac0JqeXA1QmRBcmlRbHc#gid=0
[20:06] <tdonohue> ok, finally loaded for me
[20:06] <tdonohue> so, shall we start at the top then?
[20:06] <hpottinger> I've hilighted all rows that aren't currently merge able (aka "dirty" or "unstable")
[20:06] <mhwood> Newest are at the top.
[20:07] <helix84> hpottinger: Is this sorted by priority? If so, please move DS-1475 as I'm currently incorporating changes suggested in review.
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1475 ] - [#DS-1475] Improvement of Collection Dropdown - DuraSpace JIRA
[20:07] <hpottinger> current sort is "newest first"
[20:07] <hpottinger> we haven't yet prioritized
[20:08] <mhwood> Just started looking at it this afternoon.
[20:08] <hpottinger> same here
[20:09] <tdonohue> so, do we suggest just going "newest first" or going to "oldest first"? Either is fine by me, just wondering what the RT would recommend here.
[20:09] <hpottinger> certain things "jump out" like when you run across your own name in the "assignee" column
[20:09] <helix84> tdonohue: I'd recommed prodding the old ones forst
[20:10] <mhwood> Older ones should get attention or they'll stay older.
[20:10] <tdonohue> Also, as a note, I suggest we intentionally skip any PRs that relate to *bugs*. We need to concentrate on New Feature PRs (and I notice there's a combo of both in this spreadsheet)
[20:10] <mhwood> How do we use "assignee" anyway?
[20:10] <tdonohue> Ok, starting from the bottom then..
[20:11] <hpottinger> last year, we had a big "merge fest", I'm not suggesting we do that, but if we look at the old ones you can see most of them aren't merge able as-is
[20:11] <bollini> we should try to make a RT member as assignee where there are no one else
[20:11] <mhwood> Start with oldest mergeable?
[20:12] <bollini> so to be able to finalize or withdrawn most of the PRs during this week
[20:12] <hpottinger> bollini: I agree, provisionally, as long as the RT is still accepting members :-)
[20:12] <tdonohue> wait, isn't this spreadsheet just a listing of *all* PRs? I notice there's 56 lines, and 56 PRs listed here: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:12] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:12] <hpottinger> yes, this spreadsheet is all PRs
[20:12] <mhwood> PRs don't have target versions, do they?
[20:12] <bollini> the RT will accept members at any time ;-)
[20:12] * l_a_p (~chatzilla@host145-88-dynamic.19-79-r.retail.telecomitalia.it) has joined #duraspace
[20:13] <hpottinger> which is why I sorted newest first
[20:14] <tdonohue> Ok, I'm just gonna go through all PRs then, oldest first. If the PR is unmergeable, I suggest we skip it. However, the RT might want to reach out to people who have an unmergeable PR to ask if they want to update for 4.0 review.
[20:14] <mhwood> That sounds proper.
[20:15] <hpottinger> tdonohue: sounds like a good plan, I do have an update on the SWORD2 PR
[20:15] <tdonohue> That being said, skipping #47, 50, 51, 61, 78 (all are unmergeable)
[20:15] <helix84> hpottinger: as per today's email thread, Richard is going to update SWORD2 it to latest codebase; help is welcome
[20:15] <tdonohue> So, first up is #94: https://github.com/DSpace/DSpace/pull/94
[20:15] <kompewter> [ DS-1278 add a link to More Submissions at the bottom of Recent Submissio... by ottenhoff · Pull Request #94 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/94
[20:15] <tdonohue> DS-1278
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1278 ] - [#DS-1278] Provide a link to More Submissions at the bottom of Recent Submissions - DuraSpace JIRA
[20:16] <helix84> this one is obsoleted by DS-1188
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1188 ] - [#DS-1188] collection view doesn't show content by default - DuraSpace JIRA
[20:17] <tdonohue> Ok, so assuming we accept Ds-1188, we would close this one.
[20:17] <helix84> yes, I hope to get to testing it this weekend
[20:18] <tdonohue> skipping #94 for now then (but leaving open until a decision is made)
[20:18] <tdonohue> next up: https://github.com/DSpace/DSpace/pull/159 (DS-1433)
[20:18] <kompewter> [ DS-1433 add site-wide facets for /community-list by helix84 · Pull Request #159 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/159
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1433 ] - [#DS-1433] Communities & Collections page in Discovery should show facets - DuraSpace JIRA
[20:19] <bollini> I recommend to reject
[20:19] <bollini> it is not clear what facets on community should be
[20:19] <helix84> we discussed this one here at [20:07]: http://irclogs.duraspace.org/index.php?date=2013-05-15
[20:19] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2013-05-15
[20:19] <bollini> when we will have more metadata on community we can build facet upon community metadata
[20:20] <tdonohue> To clarify here. Community & Collection *homepages* already show facets. It's this page that doesn't: http://demo.dspace.org/xmlui/community-list
[20:20] <kompewter> [ Community List ] - http://demo.dspace.org/xmlui/community-list
[20:20] <bollini> yes, but community and collection home page are show case as the repository home page
[20:22] <bollini> it is a very small theme change we can always post it in a wiki page
[20:23] <bollini> just want to avoid to put some confusing content that we can manage properly in a (hope) near future
[20:23] <helix84> bollini: sorry, I'm not sure what you mean by properly
[20:23] <tdonohue> Since other "browse" pages don't show facets: e.g. Browse by Date, Browse by Title, Browse by Author , I'm leaning towards a -1 here too. Browse by Community & Collection (http://demo.dspace.org/xmlui/community-list) also shouldn't show facets unless all others do too
[20:24] <tdonohue> Currently, Facets only make sense on the Homepage, and Individual Communities & Collections. We already have facets in those locations though, so there's nothing to fix there
[20:24] <bollini> community-list show only "communities" so facets should be related to community metadata
[20:25] <helix84> bollini: can you give me an example of a community facet?
[20:25] <bollini> if we have a community metadata "dc.type" with values like "Library", "Department", etc. we can build a facet
[20:26] <hpottinger> I agree with bollini and tdonohue, and if a developer wants to add facets to other pages anyway, it's do-able
[20:26] <helix84> bollini: ok, I understand
[20:26] <tdonohue> I think we have two -1 votes here, which means this is rejected. I'd suggest we cannot get into extremely deep discussions or otherwise we'd never get through these PRs
[20:27] <bollini> ok. helix84 can you post the discussion on the PR and write a wiki page in the next days?
[20:27] <tdonohue> so, #159 / Ds-1433 is rejected... moving along
[20:27] <tdonohue> skipping over #161 as it's unmergeable
[20:28] <bollini> #183 is a bug
[20:28] <tdonohue> ok, moving on then to: https://github.com/DSpace/DSpace/pull/186 (DS-1028)
[20:28] <kompewter> [ DS-1028: CAS authentication by misilot · Pull Request #186 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/186
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-1028 ] - [#DS-1028] Single Sign-On CAS plugin for DSpace 1.7.2 - DuraSpace JIRA
[20:30] <mhwood> I've made a start on reconciling 186 and 222. CAS is hard to characterize in the general case.
[20:30] <tdonohue> ok, yea, looks like #222 is a different implementation: https://github.com/DSpace/DSpace/pull/222
[20:30] <kompewter> [ DS-1028 Implementation of CAS (Single Sign-On) authentication for DSpace by nkneumann · Pull Request #222 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/222
[20:31] <mhwood> People have been building CAS plugins all over, but they have always turned out to be site-specific.
[20:31] <bollini> just noted that #186 is about cas 2.1 (very old)
[20:31] <helix84> mhwood: would it help to have several CAS plugins in DSpace?
[20:31] <tdonohue> Generally speaking, this sounds like a good idea to add to DSpace, but I've never really used CAS auth, so not familiar with the issues at hand.
[20:31] <mhwood> I hope not. :-/
[20:32] <bollini> cas 2 and cas3 jar not live well togheter
[20:32] <tdonohue> so, should we set review of this aside to see if the two implementations can be reconciled?
[20:33] <tdonohue> Or, is there a better way forward here?
[20:33] <bollini> we use cas but probably put a cas implementation available out-of-box in dspace will make difficult the use of the other one (3 vs 2)
[20:34] <mhwood> So maybe we *do* need two, but now we know they're CAS2 and CAS3.
[20:34] <mhwood> That helps.
[20:35] <tdonohue> In any case, I'd be +1 getting either (or both) into 4.0, if it's doable. But, I don't know that'd I'd be able to help test or anything (from lack of familiarity). Also, either would need some new documentation obviously.
[20:35] <mhwood> (We actually have our own CAS plugin here just about to go into production, but IU hacked its own version of CAS and doesn't interwork with the others. Grrr.)
[20:36] <bollini> I can give a try to the CAS3 implementation in the next days
[20:36] <tdonohue> So, it sounds like mhwood & bollini will work on these? should we move along for now then?
[20:37] <mhwood> Yes.
[20:37] <tdonohue> ok, moving on. Skipping #188 as it's a bugfix
[20:37] <tdonohue> next is: https://github.com/DSpace/DSpace/pull/189
[20:37] <kompewter> [ SSO authentication module - RemoteUser by iwellaway · Pull Request #189 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/189
[20:38] <bollini> l_a_p: please do a porting to the jspui and start testing #222 ;-)
[20:38] <tdonohue> hmm.. #189 has a comment from our last review, and no response from author since then
[20:38] <mhwood> 4 months ago.
[20:39] <tdonohue> yep. So, that likely implies this one only "gets in" if someone wants to take it over
[20:39] <l_a_p> bollini: ok
[20:39] <tdonohue> (or if the author, iwellaway, suddenly responds)
[20:39] <mhwood> Needs champion.
[20:40] <hpottinger> is it really "clean"? the comment from tdonohue implies there is an issue
[20:40] <tdonohue> Ok, skipping over #189 then, as it needs updates.
[20:40] <tdonohue> hpottinger: I think it's "clean" in that it builds..but not necessarily "clean" code
[20:40] <bollini> I suggest to be clear here: no news, no volunteer, no in 4.0
[20:40] <tdonohue> bollini: correct
[20:41] <hpottinger> bollini: +1
[20:41] <tdonohue> #189: no news, no volunteer, not in 4.0
[20:41] <mhwood> Yes, if a PR has issues, mergeable or not, we need contact with the submitter.
[20:41] <bollini> we should send an email with the list of PRs that are not ready to merge in 4.0 so to allow authors to make upgrade
[20:41] <tdonohue> moving along, #190 : https://github.com/DSpace/DSpace/pull/190
[20:41] <kompewter> [ Social Sharing Bar and Export to bibtex, RIS and Mendeley by lyncodev · Pull Request #190 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/190
[20:41] <mhwood> Or a new champion.
[20:42] <tdonohue> bollini: that's a good idea. I'd recommend the RT send that email, if you feel it's worthwhile
[20:42] <tdonohue> #190 is related to DS-1493
[20:42] <kompewter> [ https://jira.duraspace.org/browse/DS-1493 ] - [#DS-1493] Sharing and Export Bar - DuraSpace JIRA
[20:42] <mhwood> 190 not mergeable.
[20:42] <tdonohue> oh whoops. my mistake.
[20:42] <tdonohue> skipping #190, as it's not mergeable
[20:43] <tdonohue> skipping #192 (bug fix)
[20:43] <tdonohue> skipping #195 (bug fix)
[20:43] <bollini> I'm not a google doc user... can someone make the change in the doc so to track NOT in 4.0 ?
[20:44] <mhwood> That requires JOINing with some source of that information, such as JIRA.
[20:44] <tdonohue> skipping #196 (bug fix)
[20:44] <hpottinger> a new column? "in 4.0?"
[20:45] <tdonohue> hpottinger: sounds good
[20:45] <bollini> hpottinger: yes, with values: probably yes / no / bug fix
[20:45] <tdonohue> we also may want a column for "bug fix" vs. feature
[20:45] <tdonohue> or, we do as bollini suggests :)
[20:45] <mhwood> Just SELECT stuff FROM GitHub, JIRA WHERE jira.version = 4.0 OR jira.version IS NULL
[20:45] <tdonohue> next up is #202 : https://github.com/DSpace/DSpace/pull/202 (DS-1508)
[20:45] <kompewter> [ Multilingual help for JSPUI by lyncodev · Pull Request #202 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/202
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-1508 ] - [#DS-1508] Multilingual Help improvement for JSPUI - DuraSpace JIRA
[20:47] <tdonohue> #202 also has had no response from joao. As noted in comments, the related ticket was closed and status is uncertain
[20:47] <hpottinger> columns created, I will have difficulty capturing data in them and following discussion
[20:48] <tdonohue> hpottinger: someone can always use the logs later
[20:48] <tdonohue> (I'm noting status here as we go)
[20:48] <helix84> well, it was closed by claudia, but it seems that was a misunderstanding
[20:48] <helix84> she thought this adds multilingual supposrt, which we already had; but this improves it
[20:49] <mhwood> Are there remaining issues with the patch?
[20:50] <helix84> it's not ideal, but that's an issue with our i18n overall, not this patch. this patch improves status quo.
[20:50] <mhwood> And it's mergeable.
[20:50] <helix84> bollini: what do you think?
[20:50] <mhwood> Is this a direction we want to go? If so, and it works, better beats perfect later.
[20:50] <helix84> mhwood++
[20:51] <bollini> I'm not sure about the need to multiple css for languages
[20:51] <bollini> probably this as been done for background image but it will add lot of duplication
[20:51] <helix84> bollini: that can be fixed later, but it wouldbe a pity to let this large piece of work go to waste if it can be improved later
[20:51] <tdonohue> yea, not too fond of the amount of duplication here. :(
[20:52] <tdonohue> I guess we can let it slide, but it's a bit "rough" around the edges... The only way to do a translation is to know HTML, generate new images, etc
[20:53] <bollini> helix84: mmm... really not sure here, I'm 0 with that
[20:54] <tdonohue> yea, I mean it's nice that you *can* create translated copies now. But the translation process is even worse than the messages.properties + messages.xml, etc.
[20:55] <mhwood> So it seems that the question is do it now and improve it later, or improve it slightly later and merge it in 5.0 a year from now.
[20:55] <bollini> just to note that this pr is about a translation it doesn't enable translation
[20:56] <mhwood> I will defer to those who deal with translation more than I do, which is a lot of people.
[20:56] <helix84> I'm +1. We'll need to do an i18n revamp anyway, so IMHO no need to wait with content for the perfect infratructure.
[20:56] <bollini> we can already translate the help, no need to move the english version under an en folder
[20:57] <mhwood> How does this square with the stock Java property-bundle approach?
[20:57] <helix84> mhwood: that hurts mu translator ears :(
[20:58] <helix84> mhwood: .properties is relatively cumbersome to use by translators. It's just one thing that Java doesn't do very well, comparatively.
[20:59] <helix84> mhwood: so you want to migrate away from it, not towards it
[20:59] <tdonohue> My only worry is whether this creates more "boundaries" in fixing our translation processes. We're creating more "hardcoded" content that isn't easily translatable, and where will people contribute new translations to this?
[21:00] <tdonohue> I'm a 0, but I have some reservations here. I don't understand the proposed way that folks can contribute more translations... It's murky and not sure if it confuses things even more
[21:01] <mhwood> OK, helix84, if there is a good reason to reinvent wheels, it should be done.
[21:01] <hpottinger> just a note, the link to the PRs in the Google doc has been fixed up a tiny bit, to be directly usable (instead of an API link), and, erm, yeah, I'm not above making a sweeping change in the middle of a discussion in progress, *I'm a professional* :-)
[21:02] <mhwood> Does this need to wait for a higher-level design pass over L10N?
[21:02] <helix84> mhwood: I definitely think this is the case. But the Java ecosystem is huge, so I'm not holding my breath for a commonly accepted standardized solution anytime soon.
[21:02] <helix84> mhwood: who would do such pass?
[21:02] <mhwood> Better wheels for DSpace is what I meant. If the Java community wants to follow along, even better.
[21:02] <bollini> I'm thinking if an external folder for the help could be useful here. In this way external help translation can be just a .zip file
[21:03] <tdonohue> If I understand this correctly, we'll now be accepting translations to DSpace/dspace-api-lang, DSpace/dspace-xmlui-lang and now DSpace/DSpace (for this).
[21:03] <helix84> mhwood: Yep, Joao even started: https://github.com/lyncode/xliff-translate
[21:03] <kompewter> [ lyncode/xliff-translate · GitHub ] - https://github.com/lyncode/xliff-translate
[21:04] <helix84> bollini: what do you mean by external?
[21:04] <bollini> something like an "help-content" folder in the dspace installdir
[21:05] <bollini> that is served by a servlet like the BitstreamServlet acts for the assetstore
[21:06] <helix84> bollini: I see what you mean, I'm just not sure why bother with it for static content.
[21:07] <bollini> just to avoid the need to repackage the webapp or requires the people to setup an additional piece (apache http virtual host with static content)
[21:07] <helix84> good point
[21:08] <hpottinger> our hour is up, do we want to keep going, or set up another time to keep at this list of PRs?
[21:08] <mhwood> I have to leave, so another time would work best for me.
[21:08] <tdonohue> I think my only problem here is that this "static content" is in DSpace/DSpace. I thought part of the point was to try and pull these translations out into a separate place (so they can potentially be managed separately from the main codebase). I know we definitely are not there yet, but this seems to be going in the opposite direction (encouraging translators to now also submit patches right to DSpace/DSpace)
[21:08] <helix84> hpottinger: I'm in favour of a dedicated review meeting
[21:09] <hpottinger> same time, tomorrow?
[21:09] <tdonohue> We do have next week (10/16) also scheduled for reviews. But, we probably still need a dedicated meeting
[21:09] <mhwood> I can do that
[21:09] <bollini> mmm... no for me
[21:09] <bollini> can we change the time?
[21:09] <helix84> bollini: what hour would suit you?
[21:10] <tdonohue> is earlier better? (we don't have anyone from NZ here today, so we could see if an earlier meeting time works to ensure bollini & helix84 don't need to be logging in from home)
[21:11] <bollini> it will be good to anticipate of 10-12 hours but not tomorrow, Friday
[21:11] <hpottinger> earlier is fine with me
[21:12] <helix84> bollini: I didn't understand. Did you mean Friday 10-12 CEST or 22-24 CEST?
[21:12] <mhwood> I have meetings in the morning but could get out of them if necessary. After 11:30 UTC-4 all is clear.
[21:12] <tdonohue> It might be best to talk in UTC. normally this meeting is at 20:00 UTC. http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0&p1=0
[21:12] <kompewter> [ Event Time Announcer ] - http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0&p1=0
[21:13] <hpottinger> 10/10 and 10/11 are all clear for me, name a time
[21:13] <tdonohue> 15:00 UTC? 16:00 UTC? earlier than that?
[21:14] <bollini> something between http://www.timeanddate.com/worldclock/fixedtime.html?hour=6&min=0&sec=0&p1=0
[21:14] <kompewter> [ Event Time Announcer ] - http://www.timeanddate.com/worldclock/fixedtime.html?hour=6&min=0&sec=0&p1=0
[21:14] <bollini> http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0&p1=0
[21:14] <kompewter> [ Event Time Announcer ] - http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0&p1=0
[21:16] <tdonohue> 6:00 UTC is middle of the night for most of USA (1:00 AM for me). 14:00 UTC or 15:00 UTC might be doable as that's beginning of the work day
[21:16] <hpottinger> http://www.timeanddate.com/worldclock/fixedtime.html?hour=13&min=0&sec=0&p1=0 is tough for me, (8am, I'm getting kids to school)
[21:16] <kompewter> [ Event Time Announcer ] - http://www.timeanddate.com/worldclock/fixedtime.html?hour=13&min=0&sec=0&p1=0
[21:16] <mhwood> Yes, I'm clear 1200-1400 UTC and could do a couple of hours earlier from home if need be.
[21:17] <bollini> 13 UTC will be very good for me (on Friday)
[21:17] <hpottinger> though, I could check in from home and order the kids to walk to school
[21:18] <helix84> 13 UTC should be doable for me
[21:18] <bollini> also 14:30 UTC is good
[21:18] <bollini> http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=30&sec=0&p1=0
[21:18] <kompewter> [ Event Time Announcer ] - http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=30&sec=0&p1=0
[21:19] * kstamatis (b03a994b@gateway/web/freenode/ip.176.58.153.75) Quit (Ping timeout: 250 seconds)
[21:19] * kstamagis (b03a90f5@gateway/web/freenode/ip.176.58.144.245) has joined #duraspace
[21:19] <tdonohue> I'm just realizing I have morning meetings the next few days. I may be able to join late (or "lurk" while I'm in my conf calls), but I'm not really available till 15 UTC on Fri.
[21:19] <mhwood> 1300 would be better for me. But I have to leave now in any case. I'll check the log to see what was decided.
[21:19] <mhwood> Friday is wide open for me.
[21:20] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:20] <tdonohue> I'd encourage you all to schedule amongst yourselves and I'll do my best to "lurk" in. But, someone else may need to run the mtg
[21:21] <hpottinger> I nominate mhwood, our the 4.0 RC (and he recently left the room so he can't object) to run the meeting
[21:22] <tdonohue> sorry, my next few mornings are just a bit packed. But, since it sounds like I'm the only one who may not be able to make it, I'd say go ahead without me and I'll catch up/lurk as best I can
[21:22] <hpottinger> sounds like 13UTC on Friday is the time
[21:23] <bollini> ok for me
[21:23] <tdonohue> So, we left off today at #202 (which seemed to still be under some discussion)
[21:23] <tdonohue> On Friday though you'd start at #205 (or #202 if you want to touch on it more)
[21:24] <hpottinger> 13 UTC appears to be 2am for NZ, so if they want to come, they'll need coffee
[21:24] <bollini> ok, I suggest to close with an appointment for Friday at 13 UTC
[21:24] <bollini> I have setup a doodle here
[21:24] <bollini> http://doodle.com/4mphdxb37a8uytkt
[21:24] <kompewter> [ Doodle: DSpace PR review ] - http://doodle.com/4mphdxb37a8uytkt
[21:25] <bollini> if we can get a better agreement we will send an email to the dspace-release list
[21:27] <tdonohue> My final note on #202: I do have some big concerns (noted above) about the translation contribution process should we merge #202. I'm not sure I like having translations coming into three different places (dspace-api-lang, dspace-xmlui-lang and main DSpace repo). But, I don't have any other "quick solutions", so I'll stay a 0 vote as of now.
[21:27] <tdonohue> bollini: good idea, I'll fill out my availability for your doodle
[21:30] <hpottinger> tdonohue: we're adjourned?
[21:32] <tdonohue> oh yes, sorry. Adjourned, unless we want to discuss #202 more. I'll be around for a little bit, but we won't do any other reviews
[21:33] <hpottinger> to make this doc easier to find: http://tinyurl.com/ds4-PR-review
[21:33] <kompewter> [ Google Docs - Online documents, spreadsheets, presentations, surveys, file storage and more ] - http://tinyurl.com/ds4-PR-review
[21:41] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:48] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:58] * kstamagis (b03a90f5@gateway/web/freenode/ip.176.58.144.245) Quit (Quit: Page closed)
[22:01] * l_a_p (~chatzilla@host145-88-dynamic.19-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258])
[22:10] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:40] * joaomelo (~jmelo@host86-144-15-244.range86-144.btcentralplus.com) has joined #duraspace
[23:01] * bollini (~chatzilla@87.18.60.109) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258])
[23:37] * joaomelo_ (~jmelo@host86-144-175-152.range86-144.btcentralplus.com) has joined #duraspace
[23:38] * joaomelo (~jmelo@host86-144-15-244.range86-144.btcentralplus.com) Quit (Ping timeout: 245 seconds)
[23:38] * joaomelo_ is now known as joaomelo
[23:53] * joaomelo (~jmelo@host86-144-175-152.range86-144.btcentralplus.com) Quit (Quit: joaomelo)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.