Timestamps are in GMT/BST.
[12:28] -verne.freenode.net- *** Looking up your hostname...
[12:28] -verne.freenode.net- *** Checking Ident
[12:28] -verne.freenode.net- *** Found your hostname
[12:28] -verne.freenode.net- *** No Ident response
[12:28] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[12:28] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[12:28] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[14:15] * sp_ (80c25750@gateway/web/freenode/ip.128.194.87.80) has joined #duraspace
[14:18] * sp_test (80c25750@gateway/web/freenode/ip.128.194.87.80) has joined #duraspace
[14:18] <sp_test> testing IRC chat
[14:19] <sp_> testing IRC chat
[14:21] * sp_ (80c25750@gateway/web/freenode/ip.128.194.87.80) Quit (Quit: Page closed)
[14:21] * sp_test (80c25750@gateway/web/freenode/ip.128.194.87.80) Quit (Client Quit)
[15:33] * grahamtriggs1 (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[15:35] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (Ping timeout: 252 seconds)
[16:05] * grahamtriggs1 (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[17:02] <tdonohue> Hi All, my weekly Office Hours starts now (for next 3 hours). If you want to talk DSpace, just let me know! https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[19:30] * Maura (80c1a3fa@gateway/web/freenode/ip.128.193.163.250) has joined #duraspace
[19:30] * Maura (80c1a3fa@gateway/web/freenode/ip.128.193.163.250) Quit (Client Quit)
[19:48] * helix84 (a@195.113.97.174) has joined #duraspace
[19:54] <tdonohue> Reminder: DSpace Developer Mtg at the top of the hour (~7mins): https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-25
[19:59] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[19:59] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:00] <tdonohue> Hi all, it's that time again. Time for DSpace Devel Mtg. Looks like our numbers are a bit small, but hopefully others will show up shortly... https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-25
[20:01] <tdonohue> We'll start things off with JIRA review as always..
[20:01] * richardrodgers (~richardro@pool-173-48-255-197.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <tdonohue> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1078+ORDER+BY+key+ASC
[20:01] <helix84> I've got 1078 covered, together with DS-1180. This will also merge LDAPAuthentication and LDAPHierarchicalAuthentication, one plugin can do both things. I just need to do some more testing, but I expect to have it ready soon to make it into 3.0.
[20:01] <tdonohue> Starting off today with DS-1078
[20:01] <tdonohue> ok, so we can skip DS-1078, helix84?
[20:01] <helix84> yep
[20:02] * tdonohue notices a lack of kompewter...I'll paste in links
[20:02] <tdonohue> ok, we'll move on to https://jira.duraspace.org/browse/DS-1079
[20:02] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[20:03] * tdonohue just woke up kompewter on demo.dspace.org
[20:04] <tdonohue> anyone tried/tested our authority control code recently? Looks like DS-1079 is talking about that in XMLUI. Any takers/volunteers?
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1079 ] - [#DS-1079] Authority Control getMatches - DuraSpace JIRA
[20:05] <helix84> i tested some authority code from Keiji Suzuki recently, but this has more to do with submission process and I don't know anything about it because I don't use it
[20:05] * PeterDietz (~peterdiet@128.146.173.112) has joined #duraspace
[20:06] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:07] <tdonohue> ok, an utter lack of takers on DS-1079. I'll guess that this one just needs a volunteer to investigate & implement. Summary: Add comment saying this needs volunteer.
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1079 ] - [#DS-1079] Authority Control getMatches - DuraSpace JIRA
[20:07] <tdonohue> we'll move along for now...
[20:07] <mdiggory> Hello Everyone
[20:07] <tdonohue> next up, DS-1080
[20:07] <PeterDietz> hi
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1080 ] - [#DS-1080] Search results preview - DuraSpace JIRA
[20:07] <tdonohue> oh, this one is assigned to mdiggory, I see :) (good timing mdiggory! hi!)
[20:08] <mdiggory> premonition
[20:08] <tdonohue> need any help on this one, mdiggory, or should we just skip it?
[20:08] <mdiggory> I think the most important thing is that what we are doing is in Discovery
[20:09] <mdiggory> So its not the general search case
[20:09] <helix84> just one thubms-up comment for directly accessing solr data -
[20:09] <helix84> you don't have to do ajax calls for that. the alternative is XSLT document() call
[20:10] <mdiggory> we actually increased the Discovery "Data Model" to support rendering Solr result details directly in the DRI, no specific referencesets.
[20:10] <mdiggory> no specific use of javascript
[20:11] <helix84> can you point me to some basic reference about that?
[20:11] <tdonohue> Is this work something you plan to submit for approval for 3.0? Can we see the code somewhere?
[20:11] <helix84> that should be very useful
[20:11] <mdiggory> we presented on it at the conference and are in the process of finalizing what will emerge as a contribution
[20:12] <helix84> any link please?
[20:12] <mdiggory> We've got a pretty full pipeline of contributions that is about to get opened up.
[20:12] <tdonohue> ok. I suggest then that we table Ds-1080 until we get more info.
[20:12] <PeterDietz> I do think that there is sensitive information sitting directly in SOLR, so if your ajax request could view it... so could the world, unless you also are glueing in some additional security
[20:12] <mdiggory> helix84: patience....
[20:13] <tdonohue> Ok, Ds-1080 Summary: @mire is working on something for Discovery...for possible inclusion for 3.0. Tabling this ticket until we get more info
[20:13] <tdonohue> last one for today, DS-1081
[20:13] <mdiggory> I'm trying to find the conference presentation
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1081 ] - [#DS-1081] Ensure that DSpace 1.8.1 can run on java 7 - DuraSpace JIRA
[20:14] <mdiggory> tdonohue: yea, that is fine.
[20:14] <tdonohue> RE: Ds-1081 -- I'll note that demo.dspace.org is now running DSpace 1.8.2 + Java 7. Seems to be working fine (though I had to tweak POM settings to get it to compile)
[20:14] <richardrodgers> Pretty sure the solr/lucene issues have been long addressed…
[20:15] <robint> tdonohue: Oracle/Sun or OpenJDK ?
[20:15] <tdonohue> demo.dspace.org is running Oracle Java 7
[20:15] <mdiggory> we also recently upgraded solr again
[20:16] <PeterDietz> For 7, isn't the OpenJDK the "reference implementation"
[20:16] <tdonohue> I'll add a comment to Ds-1081 with what is running on demo.dspace.org (meant to do that, just hadn't gotten to it). I suspect that this is *fixed* like others have said.
[20:16] <mdiggory> https://github.com/DSpace/dspace-solr/tree/dspace-solr-parent-3.5.0.1
[20:16] <mhwood> Yes
[20:16] <kompewter> [ DSpace/dspace-solr at dspace-solr-parent-3.5.0.1 · GitHub ] - https://github.com/DSpace/dspace-solr/tree/dspace-solr-parent-3.5.0.1
[20:16] <helix84> PeterDietz: it is, but they still build binary Oracle release from the OpenJDK codebase
[20:17] <helix84> PeterDietz: the difference is that the 7 is not redistributable as <7 was, so you won't find it in distributions => only OpenJDK
[20:17] <tdonohue> well, if we can get DSpace to also work fine with OpenJDK as well, I'd be all for it. I suspect we should have a *separate* ticket on OpenJDK though, as currently DSpace only claims to ever support Oracle/Sun.
[20:18] <mhwood> Running on OpenJDK 6 here.
[20:18] <helix84> i always ran dspace on OpenJDK, currently OpenJDK 6
[20:18] <tdonohue> hmmm...so, why do our Install instructions not say that? :) Didn't realize folks were running it on OpenJDK with success
[20:19] * helix84 wonders if that has something to do with the binary cult of Sun
[20:19] <tdonohue> We can switch demo.dspace.org to OpenJDK 7 if we wanted to. I only went through the hassle of installing Oracle Java 7 cause I thought there were still problems to work out on OpenJDK
[20:20] <mdiggory> so we are still on solr 3.3.0, there will be an update coming to bring it up to 3.5.0, may be part of discovery work.
[20:20] <PeterDietz> I've noticed that Java6SE, has an end-of-life of November 2012. (i.e. no public support). Which means that moving to JDK7 is probably going to be on everyone's radar this fall?
[20:21] <richardrodgers> I'd think so - no more security patches etc
[20:21] <helix84> there are some warnings about deprecated Solr functions in logs, am I correct they're a harmless consequence of running an older Solr?
[20:21] <tdonohue> +1 PeterDietz. Yea, another reason it'd be nice to announce that DSpace 3.0 supports *both* Oracle Java 7 and OpenJDK 7
[20:23] <tdonohue> Ok, in any case, I'm assuming Ds-1081 may be fixed. We should just make an effort to test both Oracle Java 7 & OpenJDK 7 during 3.0 Testathon
[20:23] <richardrodgers> If we were ambitious, we could 'certify' earlier releases on Java7 (e.g. 1.8)
[20:23] <hpottinger> sounds like some of us have done so already :-)
[20:24] <helix84> we should think of what we "support" as what most people are running, therefore users can get help with that from most users. I'm fine with supporting users running OpenJDK.
[20:24] <mdiggory> note, upgrading solr to 3.5 is going to require dumping and restoring solr indexes. Especially in the statistics case.
[20:25] <tdonohue> I will note that in order to get 1.8.2 to compile using Oracle Java 7, I did have to update POM settings -- so, to fully "certify" 1.8 on Java 7, we'd need to cut a 1.8.3, I believe
[20:25] <helix84> mdiggory: there was an issue for that upgrade, can you just comment that we must mention that in release notes?
[20:25] <mdiggory> note... http://opensearchnews.com/2012/04/announcing-java7-support-with-apache-solr-and-lucene/
[20:25] <kompewter> [ Announcing Java7 Support with Apache Solr and Lucene | Open Search News ] - http://opensearchnews.com/2012/04/announcing-java7-support-with-apache-solr-and-lucene/
[20:26] <mdiggory> as of solr 3.6
[20:26] <tdonohue> mdiggory -- demo.dspace.org seems to be having no issues running Solr/Lucene on Java 7. Or at least, I haven't noticed any yet.
[20:27] <tdonohue> mdiggory -- but, this may mean we'd want to ensure we get Lucene & Solr upgrade into 3.0 just to be safe
[20:27] <PeterDietz> I'm wondering how long reprocessing your archived dspace.log files (into solr / elasticsearch) for a few years would take?
[20:28] <mdiggory> we may not be triggering the problem in lucene that existed.
[20:29] <tdonohue> I think we're starting to wrap up Ds-1081 discussion...several things noted -- Summary: DSpace seems to work fine on Oracle Java 7 & OpenJDK 7 (but Testathon will help) & we should likely upgrade Lucene & Solr to 3.6
[20:29] <tdonohue> I think we can wrap up the JIRA discussion for today, and move on to 3.0 stuff (though admittedly much of this was already 3.0 related)
[20:30] <tdonohue> Essentially, I just wanted to ask whether there are features we want to start a more detailed review on for 3.0. We have many "tentative" features listed here: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-NewfeaturesinDSpace3.0%28verytentative%29
[20:30] <kompewter> [ DSpace Release 3.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-NewfeaturesinDSpace3.0%28verytentative%29
[20:31] <tdonohue> We're now down to just 3 more weeks until Feature Freeze. So, we need to start getting things approved soon!
[20:31] <helix84> I'm glad XOAI is getting more eyballs
[20:31] <tdonohue> 3.0 Release Team members -- is there anything you are wanting to discuss / touch on today?
[20:34] <hpottinger> I'll pipe up, I mentioned this on the release list last week, but there are a few issues with patches, but no pull requests, we'll need to round those up and decide if we want to turn them into pull requests ourselves, or send them back to the issue reporter for conversion into pull requests.
[20:34] <helix84> mdiggory, any new info in Metadata for all?
[20:35] <mhwood> Brief mention: I hope to have something for DS-1206 (Total-Impact integration) soon.
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-1206 ] - [#DS-1206] Alternative Metrics - Integration of Total-Impact on item pages - DuraSpace JIRA
[20:35] <tdonohue> hpottinger -- good point. Do we have a list of these tickets with patches somewhere? (Or somewhere we could start compiling them?) I'd be glad to help chip in on converting to pull requests little by little if needed.
[20:36] <tdonohue> mhwood -- cool! Should we assign that ticket to you then?
[20:36] <hpottinger> tdonohue: not yet, something I want to do, I figure just a post to dspace-release would work
[20:36] <helix84> tdonohue: maybe we could use Jira labels or epic for "has patch"
[20:36] <mhwood> Sure.
[20:37] <helix84> the question is should we distinguish "has patch" and "has pull request"?
[20:37] <tdonohue> hpottinger -- yea, if we can get a list together to work from, then that'd be great
[20:38] <mdiggory> helix84: no new news on Metadata For All
[20:39] <tdonohue> RE: JIRA -- you can actually do a search for everything having *attachments* (not necessarily the same as having a patch, but close): https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Attachments+%3E%3D+1
[20:39] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Attachments+%3E%3D+1
[20:39] <hpottinger> If anyone is interested in Jira spelunking for issues with patches, could be a fun time, ooh, thanks tdonohue, that'll help
[20:40] <helix84> I can do that. Any answer to my question about labels/epic?
[20:41] <hpottinger> ok, helix84, would a wiki page for tracking these help?
[20:42] <helix84> no need, you can just filter issues with that label
[20:42] <helix84> less work, real-time
[20:42] <tdonohue> We can use some custom JIRA labels if we wanted to denote patches/pullrequests : 'has-patch' , 'has-pull-request' or similar. I'd be open to that. We just need to decide upon the label(s) to use
[20:43] <hpottinger> both labels would be helpful, especially if we could combine labels for a filter (has-patch but not has-pull-request)
[20:43] <helix84> ok, calling a quick vote: Do we want both 'has-patch' and 'has-pull-request'? +1 yes, -1 no, 0 don't care
[20:44] <hpottinger> +1
[20:44] <helix84> +1
[20:44] <mhwood> +1
[20:44] <richardrodgers> +1
[20:44] <tdonohue> +1
[20:45] <helix84> Seems the vote passed. I'll do the work.
[20:45] <tdonohue> ok, sounds good. That's all the votes we need for a "policy" related change. So, we should just start labeling tickets as "has-patch" and/or "has-pull-request"
[20:46] <tdonohue> Ok, other 3.0 Topics? Is it worth trying to figure out a "schedule" for some of these possible features?
[20:47] <helix84> you mean give a sooner deadline to individual projects that is sooner than the freeze deadline?
[20:48] <mhwood> More like getting a commitment to putting something out sooner, so they don't all land on the 17th.
[20:48] <helix84> sounds like responsibilito of the release team if they want to do that
[20:48] <tdonohue> +1 mhwood. I was talking about trying to determine "when" some of these will be ready to discuss/approve...so that it all doesn't happen at the last moment
[20:49] <robint> tdonohue: +1
[20:49] <tdonohue> Related to that, has anyone been in touch with SeDiCi about their proposed additions to 3.0? https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-NewfeaturesinDSpace3.0%28verytentative%29
[20:49] <kompewter> [ DSpace Release 3.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-NewfeaturesinDSpace3.0%28verytentative%29
[20:50] <tdonohue> I know we're in touch with Lyncode, @Mire (obviously) and I've seen discussions with CILEA. But, haven't heard anything about the SeDiCi work
[20:50] <robint> I don't actually know who they are
[20:51] <tdonohue> I don't know SeDiCi either, but it looks like one of them did open up the referenced ticket: DS-1127 -- so that could be a point of contact.
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-1127 ] - [#DS-1127] Submission improvements: document type-based submission - DuraSpace JIRA
[20:51] <helix84> no idea here
[20:52] <tdonohue> I'm not even sure if anyone has looked at the DS-1127 work, and whether it'd be under consideration... But, it'd be good to have an answer for SeDiCi since they obviously are proposing it be added to 3.0
[20:52] <kompewter> [ https://jira.duraspace.org/browse/DS-1127 ] - [#DS-1127] Submission improvements: document type-based submission - DuraSpace JIRA
[20:53] <helix84> but Nestor Oviedo has been active in Jira and -devel recently
[20:53] <robint> http://sedici.unlp.edu.ar/ ?
[20:53] <kompewter> [ SeDiCI - Repositorio de la Universidad Nacional de La Plata ] - http://sedici.unlp.edu.ar/
[20:54] <tdonohue> Looks like Nestor is the one who added the "SeDiCi" list to the 3.0 Release notes too: https://wiki.duraspace.org/pages/diffpages.action?originalId=32474694&pageId=32476772
[20:54] <kompewter> [ Page Comparison - DSpace Release 3.0 Notes (v.23 vs v.24) - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/diffpages.action?originalId=32474694&pageId=32476772
[20:54] <robint> I'll try and track him/them down and make contact
[20:54] <tdonohue> Thanks robint.
[20:55] <tdonohue> robint: Nestor's info (at least in the wiki): https://wiki.duraspace.org/display/~nesovi
[20:55] <kompewter> [ Nestor Oviedo - User Profile - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~nesovi
[20:55] <robint> thanks
[20:56] <helix84> any change we'll make it to the second agenda point today? ;)
[20:56] <helix84> s/change/chance/
[20:56] <kompewter> helix84 meant to say: any chance we'll make it to the second agenda point today? ;)
[20:57] <tdonohue> Ok. So, it sounds like we're mostly just "waiting" for things to be ready for review from 3.0. I'd just encourage us to *ahem* pester @mire and CILEA to get us their proposed changes :)
[20:57] <tdonohue> go head helix84. we can move on to some of your 3.0 questions (though we are running short of time obviously): https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-25
[20:57] <kompewter> [ DevMtg 2012-07-25 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-25
[20:58] <helix84> Where should translations of individual modules like Discovery go? Including them in the main messages.xml currently works. This should be answered before freeze time, it already poses another barrier for commiting of translations, see DS-1049, DS-1054. This is a subproblem of i18n Improvements Proposal, but let us not divert this discussion too much to broad topics.
[20:58] <kompewter> [ https://jira.duraspace.org/browse/DS-1049 ] - [#DS-1049] Czech localization of 1.8.0 - DuraSpace JIRA
[20:58] <kompewter> [ https://jira.duraspace.org/browse/DS-1054 ] - [#DS-1054] message catalog for ru_RU locale - DuraSpace JIRA
[20:58] <helix84> https://wiki.duraspace.org/display/DSPACE/i18n+Improvements+Proposal#i18nImprovementsProposal-DifficulttoLocateAllthei18nFiles
[20:58] <kompewter> [ i18n Improvements Proposal - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/i18n+Improvements+Proposal#i18nImprovementsProposal-DifficulttoLocateAllthei18nFiles
[20:58] <PeterDietz> I need to propose our Elastic Search statistics overhaul
[20:58] <tdonohue> This is an ongoing question on lists...translations are getting harder & harder for folks to manage.
[20:59] <helix84> let's just address this specific issue, please :/
[20:59] <tdonohue> helix84: sure. didn't mean to broaden the topic.
[21:00] <tdonohue> any thoughts on this? Where should translations of individual modules (e.g. Discovery) go?
[21:00] <mhwood> I'd say that (a) they should go in their modules, but (b) that's not a drop-everything issue.
[21:01] <hpottinger> yay, PeterDietz, I was wondering if that was going to make it into 3.0 (apologies to helix84 for off-topic exuberance)
[21:01] <richardrodgers> all in central file is not ideal (from modularity point of view) but the question is whether we have a feasible alternative in 3.0 timeframe
[21:01] <helix84> i'm for having them in a single messages.xml as long as the module is part of the release
[21:01] <tdonohue> Would it be bad to just suggest folks put *all* translations in the main messages.xml for 3.0?
[21:01] <mdiggory> PeterDietz: I think we need to assure alignment with any stats stuff we are pushing out as well. I expect the next two weeks to be very hectic and full of dialog...
[21:02] <robint> I'vo got to run, cheers all
[21:02] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:03] <tdonohue> It sounds like several are saying the same thing: Ideally, we'd have a good solution, but for 3.0 we should just tell folks to put all translations into the main messages.xml. Would others agree? +1/-1/0
[21:03] <helix84> +1
[21:03] <mhwood> No, but I'd agree that they can stay wherever they are for now.
[21:03] <mdiggory> +0
[21:03] <helix84> that's the problem - they weren't accepted
[21:03] <richardrodgers> is there an alternative? +0
[21:03] <helix84> because the issue wasn't decided
[21:05] <tdonohue> I don't think there is an alternative (unless we build something new for 3.0)?
[21:06] <tdonohue> I think it's a matter of -- do we just go with "what works now" for 3.0 (which is putting them all in the main messages.xml), or do we figure out a better solution before 3.0. Or at least, that's my understanding here (correct me if I'm wrong, helix84)
[21:06] <helix84> tdonohue: right
[21:07] <mhwood> Did anyone contribute a translation that's broken out by modules? If not then my caveat is pointless and I'll support all-in-one for 3.0.
[21:07] <helix84> I'm not aware of any
[21:07] <mhwood> I don't think modularized translations should be smooshed together, is all I'm saying.
[21:08] <tdonohue> I think we *HAVE* to suggest folks put module translations into the main messages.xml in 3.0, unless someone builds some new way to handle modularized (split out) translations.
[21:08] <richardrodgers> yes tdonohue that's what I meant
[21:08] <mhwood> Why wouldn't they just be found on the classpath?
[21:08] <tdonohue> mhwood -- currently, I don't think modularized translations are possible in DSpace (or at least not to my knowledge). That's the root of the issue here.
[21:09] <tdonohue> mhwood -- that's a good question, that I don't know the answer to.
[21:10] <mhwood> Well, if there are no modularized translations then the answer is simple: pile them into the main catalog, because that's the way they are now.
[21:11] <mhwood> Then we have time to work out what is doable, what is readily doable, and what is our standard practice.
[21:12] <tdonohue> yea, I think that's our "best answer" right now.
[21:14] <mdiggory> ok... so as to bring forward the first option for contribution review by the release team. I've pushed dspace3-embargo into our public github repo and generated the following pull request to the community DSpace platform.
[21:14] <mdiggory> https://github.com/DSpace/DSpace/pull/43
[21:14] <kompewter> [ Pull Request #43: [DS-895] Advanced Embargo Project by mdiggory · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/43
[21:14] <helix84> yay!
[21:15] <tdonohue> RE: translations...Thinking out loud here...I notice the 'dspace-xmlui-lang' project has a folder structure that mirrors 'dspace-xmlui-webapp' https://github.com/DSpace/dspace-xmlui-lang/tree/master/src/main/webapp/i18n
[21:15] <kompewter> [ dspace-xmlui-lang/src/main/webapp/i18n at master · DSpace/dspace-xmlui-lang · GitHub ] - https://github.com/DSpace/dspace-xmlui-lang/tree/master/src/main/webapp/i18n
[21:15] <mhwood> Features landing early...goodie!
[21:15] <tdonohue> I wonder if it'd also be possible to add folders in that 'dspace-xmlui-lang' project to mirror Discovery (and other modules): https://github.com/DSpace/DSpace/tree/master/dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery/i18n
[21:15] <kompewter> [ DSpace/dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery/i18n at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/tree/master/dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery/i18n
[21:15] <tdonohue> (And I wonder if that'd work)
[21:16] <tdonohue> sorry for the link spam...(Agreed -- yea for @mire getting features out there early)
[21:16] <mdiggory> It may be slightly ahead of its time... we are in testing as well.
[21:17] <tdonohue> mdiggory : I'd rather have it early & potentially still having a few rough edges, than late & perfect
[21:18] <mdiggory> I agree, its hard to let things go out until we are confident in the solutions ourselves.
[21:18] <mhwood> Oh, yes. But the idea is to start getting suggestions on how to make it even better. (I keep telling myself that.)
[21:18] <tdonohue> makes sense, I understand the feeling...just glad you got it posted early :)
[21:19] <tdonohue> Ok folks, we're obviously way over time. No new topics for today, but you are welcome to hang around and chat (or head out as need be). I'll still be here for another 30mins or so. Official meeting is closed
[21:19] <hpottinger> an example for us all, thanks, mdiggory
[21:19] <mdiggory> tdonohue: per the messages translations... the benefit of the separation is that they can be released separately... But TBH, if we are doing 2-3 interim releases each year... languages could probibly be included into dspace-api and dspace-xmlui and not cause too much fuss.
[21:19] <mhwood> Aaaand, I've got to run.
[21:19] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:19] <richardrodgers> gotta go, bye all
[21:20] * richardrodgers (~richardro@pool-173-48-255-197.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:20] <tdonohue> mdiggory -- I think we pretty much are always doing 2-3 interim releases each year....or at least that's been the trend
[21:20] <mdiggory> tdonohue: I could include that into the maven project consolidation fairly easily
[21:21] <tdonohue> mdiggory what is "that"? Not sure I understand what you could include?
[21:21] <tdonohue> you mean include lang packs into dspace-xmlui/api in the maven proj consolidation?
[21:21] <mdiggory> the maven project consolidation that we suggested doing as a last activity before the freeze...
[21:22] <mdiggory> would consolidate all dspace-xmlui-xxx projects into one.
[21:22] <tdonohue> right..I understand that
[21:22] <mdiggory> could have the added benefit that we just move the language files back into dspace under their original projects.
[21:22] <mdiggory> dspace-api/src/main/resources
[21:23] <mdiggory> dspace-xmlui/src/main/resources
[21:23] <mdiggory> and dspace-xmlui/src/main/webapp/i18n....
[21:23] <tdonohue> oh, so actually get rid of the 'dspace-xmlui-lang' and 'dspace-api-lang' as separate projects, and merge them into https://github.com/DSpace/DSpace/
[21:23] <kompewter> [ DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/
[21:23] <mdiggory> yes
[21:23] * helix84 is not following, but nevermind, just tell me the conclusion
[21:24] <mdiggory> helix84: conclusion, all language translations part of dspace-api or dspace-xmlui, not dspace-api-lang or dspace-xmlui-lang
[21:25] <mdiggory> that is one simplification that would reduce confusion / complexity
[21:25] <tdonohue> helix84 -- mdiggory is talking about getting rid of https://github.com/DSpace/dspace-api-lang and https://github.com/DSpace/dspace-xmlui-lang , and instead having all translations get committed to https://github.com/DSpace/DSpace/tree/master/dspace-api or https://github.com/DSpace/DSpace/tree/master/dspace-xmlui
[21:25] <kompewter> [ DSpace/dspace-api-lang · GitHub ] - https://github.com/DSpace/dspace-api-lang
[21:25] <kompewter> [ DSpace/dspace-xmlui-lang · GitHub ] - https://github.com/DSpace/dspace-xmlui-lang
[21:25] <kompewter> [ DSpace/dspace-api at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/tree/master/dspace-api
[21:25] <kompewter> [ DSpace/dspace-xmlui at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/tree/master/dspace-xmlui
[21:25] <helix84> I see
[21:25] <mdiggory> more specifically
[21:25] <mdiggory> https://github.com/DSpace/dspace-api-lang/tree/master/src/main/resources
[21:25] <kompewter> [ dspace-api-lang/src/main/resources at master · DSpace/dspace-api-lang · GitHub ] - https://github.com/DSpace/dspace-api-lang/tree/master/src/main/resources
[21:25] <mdiggory> would move here
[21:26] <mdiggory> https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/resources
[21:26] <kompewter> [ DSpace/dspace-api/src/main/resources at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/resources
[21:26] <helix84> but that would prevent any scenario with separate (possibly automated) commiters of translations
[21:27] <mdiggory> git kinda frees us from worrying about all that...
[21:27] <helix84> umm, how?
[21:27] <mdiggory> why can those translations come as various pull requests / pushes?
[21:27] <mdiggory> same as they do right now...
[21:27] <mdiggory> why can = why can't
[21:28] <helix84> well, firstly, tools like Transifex and possibly Pootle can be configured to do commits. But I don't know about pull requests (that's GitHub specific).
[21:28] <tdonohue> mdiggory: I think helix84's point is that if you have separate Git projects, you can actually give *Git Commit* permissions to different people (i.e. non-DSpace Committers), just so they can help manage translations of DSpace
[21:29] <mdiggory> are we really going to manage separate teams and worry about all that... seem like that approach (and I'm guilty as anyone in pushing for it) somewhat weakened/fragmented the comunity
[21:29] <helix84> secondly, most translators may not be able to use git, so it's preferable to have that kind of interface with automated commits
[21:29] <mdiggory> it doesn't matter where in git is is then...
[21:30] <mdiggory> automated on DSpace/DSpace vs DSpace/dspace-api-lang isn't very different.
[21:30] <helix84> well, the tool (translation interface) can be added as a separate commiter account that would commit all translations (and only translations)
[21:31] <mdiggory> TBH, most everything should be done with pull requests and additional review by a second set of eyes.... even something that was automated
[21:31] <tdonohue> mdiggory: who is going to do a pull request review of translations? Wouldn't we want someone bilingual to help with that?
[21:32] <mdiggory> clone DSpace to that automated account and commit there... have someone issue Pull requests or push back to dspace periodically
[21:32] <helix84> well, you can always review ex-post, that's the nice thing about anu VCS
[21:32] <helix84> easy to revert anything
[21:32] <mdiggory> no... the point is to make sure that something that shouldn't have changed got mixed in...
[21:33] <mdiggory> anu VCS?
[21:33] <helix84> any version control system
[21:34] <tdonohue> I'll admit I'm on the fence here (not convinced either way). I see translations as having the possibility to be managed separate from the main codebase (as you don't need committers/programmers to do/submit a translation). At the same time I can understand how (from a programmers point of view) it could be nice to simplify the number of projects we have.
[21:34] <helix84> I think we'll disagree with Mark on the point of ex-ante vs. ex-post review of translations (talking only about translations here, i.e. files in a specific path)
[21:35] <helix84> the point here is to lower the barriers for translators
[21:36] <tdonohue> I just don't want us to jump to the conclusion that translations should be consolidated into the main codebase, just cause is seems easier to programmers....
[21:36] <tdonohue> +1 helix84 on lowering the barriers to translations
[21:36] <helix84> and asking for review of translations (as in not format, the actual translations) is off-topic here and raising barriers
[21:37] <hpottinger> nice thing about pull requests is that they're easy enough to roll into your own site install, so, we'd have most of the benefit of an automated system, just with a review step from a trusted programmer before it's officially accepted
[21:37] <helix84> hpottinger: what do you mean with "site install"?
[21:37] <hpottinger> your working folder
[21:38] * helix84 is scratching his head
[21:38] <helix84> oh, ok
[21:39] <hpottinger> git automates the patch process, it's not as "difficult" as applying a patch from Jira, so using an unapproved translation is the same as trying out any new code
[21:40] <helix84> anyway, we may have gone too far into the future, there are no automated tools in preparation right now, the question was whether having a separate repository for languages is good or bad
[21:40] <helix84> and this could be done with both
[21:42] <tdonohue> One thing to remember is that when we release a new major version of DSpace (e.g. 3.0), it's usually *very rare* to have many translations immediately ready (usually we are lucky to have 1 or 2).
[21:42] <mdiggory> tdonohue: it takes a programmer to submit a translation in the appropriate format to be committed to the VCS
[21:43] <tdonohue> So, is there still a benefit to keeping language packs as separate projects, so they can be released later on once they are ready?
[21:43] <helix84> mdiggory: or an automated tool
[21:43] <mdiggory> they need to right tools to do it correctly
[21:44] <helix84> tdonohue: good point, i forgot about that
[21:44] <mdiggory> Yes and in that case, you can stick them in the center of the codebase, the tool enforces the control on what can be commited to
[21:44] <helix84> mdiggory: that was my whole idea
[21:44] <mdiggory> again, it doesn't matter where the files reside
[21:45] <mdiggory> either we release dspace 3.1 with new translations and upload to maven central or someone has to run dspace-api-lang release and upload to maven central
[21:47] <helix84> I like the separate release more. Minor releases for bugfixes, but always up-to-date translations.
[21:47] <helix84> still, could dspace-api-lang and dspace-xmlui-lang be merged? or is there a reason for them to be separate?
[21:48] <helix84> (not merged into dspace, merged one with the other)
[21:48] <mdiggory> My point is that the translations are not very up to date because it take s a release coordinator to make them available to the community.
[21:49] <mdiggory> some sit in the dspace-api-lang project until someone pulls that trigger for the community
[21:49] <helix84> so status quo is only potentially better, but not in practice?
[21:49] <mdiggory> that release is generally.... when a release coordinator is pulling the trigger on dspace release processes for a major or minor release.
[21:49] <helix84> so is there another suggestion? perhaps an ant task to pull them via HTTP from somewhere on dspace.org?
[21:50] <helix84> or from GitHub?
[21:51] <tdonohue> in practice, mdiggory is right... we tend to *only* release dspace-xmlui-lang and dspace-api-lang updates to Maven central when we go to cut a new release of DSpace. With GitHub, obviously people can download specific files themselves much easier if they want immediate fixes
[21:51] <mdiggory> we generally override them to put local customizations in place, guarantee that mechanism still is present... I imagine theres an opportunity there... but also realize that folks want offline builds as well.
[21:52] <mdiggory> \me wonders about whats in this git coolaid...
[21:52] <mdiggory> my first thought was... "merge"
[21:53] <tdonohue> I gotta head out...interesting discussion though. I'll follow up later. Right now, I'm still not convinced that merging -lang into the main DSpace GitHub is the "right move". But, I'm still open to it...just a bit skeptical. So, I'm waiting to be convinced of what we should do.
[21:53] <mdiggory> or as PeterDietz says "cherry pick"
[21:53] <helix84> mdiggory: my suggestion here was only to use GitHub as an HTTP server with the most up-to-date translations
[21:53] <mdiggory> what if that location happens to coincide with master?
[21:54] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:54] <mdiggory> or a maintence branch?
[21:54] <helix84> for this particular issue, no problem
[21:54] <mdiggory> get your cake and eat it too
[21:55] <helix84> actually, that's what i meant - for each version corresponding branch
[21:56] <helix84> so what about merging dspace-api-lang and dspace-xmlui-lang?
[21:58] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:58] <mdiggory> dspace-xmlui-lang is not required for jspui etc
[21:59] <helix84> ok, i'll have to go now
[22:00] <mdiggory> good dialog, thanks.
[22:00] <helix84> i'm not sure we reached any conclusion about the merge
[22:00] <helix84> yes, thanks. lot of hard questions to answer.
[22:01] <helix84> however, it's worth thinking about the ant task
[22:03] * helix84 (a@195.113.97.174) has left #duraspace
[22:04] * barmintor is now known as barmintor_beer
[23:09] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Remote host closed the connection)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.