Timestamps are in GMT/BST.
[5:12] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Quit: Leaving.)
[6:02] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[6:03] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[6:03] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[6:03] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:40] -asimov.freenode.net- *** Looking up your hostname...
[6:40] -asimov.freenode.net- *** Checking Ident
[6:40] -asimov.freenode.net- *** Found your hostname
[6:40] -asimov.freenode.net- *** No Ident response
[6:40] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:40] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:40] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:31] * botton (~willie@router.isis.poly.edu) has joined #duraspace
[10:31] * botton (~willie@router.isis.poly.edu) has left #duraspace
[10:50] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[10:52] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[10:53] * fasseg (~ruckus@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[10:53] * motron[ph] (~ruckus@hsi-kbw-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[10:53] * motron[ph] (~ruckus@hsi-kbw-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Client Quit)
[11:19] * eddies (~eddies@19.202-63-155.unknown.qala.com.sg) has joined #duraspace
[11:19] * eddies (~eddies@19.202-63-155.unknown.qala.com.sg) Quit (Changing host)
[11:19] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[11:49] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:14] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[12:14] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[12:14] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[13:03] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:40] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[13:58] * fasseg (~ruckus@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Ex-Chat)
[14:02] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[14:12] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Quit: Leaving)
[14:12] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[15:07] * tdonohue1 (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[15:07] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Disconnected by services)
[15:07] * tdonohue1 is now known as tdonohue
[15:15] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[17:55] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[18:59] * pbecker (5cce7fc4@gateway/web/freenode/ip.92.206.127.196) has joined #duraspace
[19:18] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:25] * pbecker (5cce7fc4@gateway/web/freenode/ip.92.206.127.196) has left #duraspace
[19:54] <tdonohue> Hi All, reminder that our weekly DSpace Developers Mtg start at the top of the hour : https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-17
[19:54] <kompewter> [ DevMtg 2013-04-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-17
[19:58] <PeterDietz> hi all
[20:01] <tdonohue> As normal, it's time for our weekly DSpace Dev mtg (agenda above)
[20:01] <tdonohue> Last week we had discussed starting things off with a Pull Request review
[20:02] <tdonohue> So, here's our most recent pulls: https://github.com/DSpace/DSpace/pulls
[20:02] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls
[20:02] <tdonohue> Perhaps we just start from the top? Or should we reorder and do "oldest" first?
[20:03] <mhwood> Oldest first, otherwise oldest will never be reviewed.
[20:03] <tdonohue> ok, here's oldest first sort: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:03] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:03] <tdonohue> we start with https://github.com/DSpace/DSpace/pull/47
[20:03] <kompewter> [ [DS-1227] Add tag cloud support in home page by EKT · Pull Request #47 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/47
[20:03] <tdonohue> which is DS-1227
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1227 ] - [#DS-1227] Tag cloud for any browse index in the home page of DSpace - DuraSpace JIRA
[20:04] <tdonohue> ok, this one looks to be "accepted" by abollini for 4.0
[20:05] <mhwood> Work outstanding, though.
[20:05] <tdonohue> yep. work is outstanding. Looks like the latest comment on Pull #47 is from abollini describing what needs to be changed
[20:06] <tdonohue> So, moving on... next pull is: https://github.com/DSpace/DSpace/pull/50 which is DS-1237
[20:07] <kompewter> [ [DS-1237] Allow date range searches in advance search by EKT · Pull Request #50 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/50
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1237 ] - [#DS-1237] Support date ranges in advanced search - DuraSpace JIRA
[20:09] <tdonohue> This seems to also be "waiting" for an update from the pull request creator (I wish there was a status for that in GitHub)
[20:10] <tdonohue> Not sure what else we can do here. The associated JIRA ticket is marked "volunteer needed" and there's comments as to what needs to be changed.
[20:11] <tdonohue> so, moving on, I guess. Next pull is: https://github.com/DSpace/DSpace/pull/51 which is DS-1238
[20:11] <kompewter> [ [DS-1238] Display advance search form after an advance search by EKT · Pull Request #51 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/51
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1238 ] - [#DS-1238] Display advance search form after an advance search - DuraSpace JIRA
[20:11] <tdonohue> Also claimed by abollini...and also waiting for specific changes to be made by pull creator.
[20:12] <tdonohue> just gonna try to get through one more here...these are all in a similar bucket
[20:13] <tdonohue> Next pull is https://github.com/DSpace/DSpace/pull/53 which is DS-1224
[20:13] <kompewter> [ [DS-1224] Export items in various bibliographic formats by EKT · Pull Request #53 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/53
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1224 ] - [#DS-1224] Export items in various bibliographic formats (as RIS, BibTeX, EndNote, IEEE,...) - DuraSpace JIRA
[20:13] <tdonohue> looks like Pull #53 can be closed. Ds-1244 is closed as "won't fix" cause of license incompatibility issues.
[20:14] <tdonohue> so, we'd need a fresh pull without any GPL stuff in it
[20:14] <mhwood> Yes
[20:15] <tdonohue> ok. we'll stop there for today, as we are 15mins in
[20:15] <tdonohue> now, we just need to *remember* where we left off, so we can skip them next week :)
[20:16] <tdonohue> err..skip over ones we've reviewed already, obviously
[20:16] <mhwood> This channel is logged.
[20:17] <tdonohue> yep. It's just not always the easiest to parse the logs, but we'll manage :) Ok, moving on anyhow
[20:17] <tdonohue> I've posted a wiki page for our OR13 DSpace Developers Mtg, including the usual "signup" form: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting
[20:17] <kompewter> [ DevMtg 2013-07-08 - OR13 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting
[20:18] <tdonohue> I'd suggest going there and signing up. The Location is still TBD (working with the conference organizers still to find a spot for us)
[20:18] <tdonohue> priority goes to Committers / DCAT members...but, *anyone* is invited. Just signup. We likely will have a maximum around 30-35 (depending on room size)
[20:18] * fasseg (~ruckus@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[20:19] <tdonohue> If you are a Committer, and you are *not* able to attend, it'd also be worth knowing (you can add your name to those who won't make it)...just so we know who to expect from our committers group.
[20:20] <mhwood> Second post!
[20:20] <tdonohue> Also, if there are any thoughts on topics to discuss, please feel free to add them to that wiki page as well (or mention them here / send me a note). The agenda is still being formed
[20:21] <tdonohue> (I added an agenda note about our discussion from last week about "empowering individuals/small groups" to move more rapidly in development of new features / fixing bugs)
[20:22] <mhwood> Good.
[20:22] <tdonohue> Any burning questions / thoughts / brainstorms about our OR13 face-to-face meeting?
[20:23] <tdonohue> (Oh, and though it's not on the wiki page, yet... I was thinking we could all head to a local pub for dinner/drinks after the OR13 meeting, as we do most years)
[20:23] <mhwood> That looks like plenty to fill an afternoon.
[20:24] <tdonohue> the two agenda items? 4.0 and "empowering people"?
[20:24] <tdonohue> I do agree, it could potentially fill much of an afternoon, or at least a few hours of it..
[20:24] <hpottinger> can I suggest a discussion of topics raised by the "Chicago meeting?"
[20:25] <mhwood> Yes, there will be a lot of discussion of both.
[20:25] <mhwood> Good point.
[20:25] <tdonohue> hpottinger - oh yea! very good point. I forgot to add that to the list of agenda topics. Will add it
[20:26] <hpottinger> It's not like we won't talk about them, but it'll be good to know we're going to be talking about them. That pretty much fills the day right there, those three things.
[20:26] <tdonohue> done. it's added.
[20:26] <tdonohue> yep, I agree. that would fill the 1/2 day meeting.
[20:27] <tdonohue> Ok. any other thoughts on OR13 before we move on?
[20:27] <PeterDietz> One thought I had, since I've been thinking API. Is to change how I might think of DSpace to be the backend repository system. And then have the lightweight API client UI sit on top. Then your university could hire Ruby on Rails developers to build a repository frontend.
[20:28] <PeterDietz> Thus, giving people who manage DSpace the chance to focus on repository/backend improvements, and then people who manage User Interfaces to fiddle with fonts, themes, etc
[20:28] <hpottinger> Stuart Lewis coined a term for that, RaaS (Repository as a Service)
[20:30] <PeterDietz> something like that. I'm not completely sure I understand the long term vision, just something to overcome struggles with cocoon et all
[20:30] <tdonohue> Yea, this all seems like it may (or may not) come up as part of either the "Vision" discussion, or possibly 4.0 (assuming REST API is geared to be "ready" by then). I agree though, it's an interesting idea, and definitely worth considering
[20:31] <tdonohue> I hope the output of the "Vision" meeting in Chicago may help us all start to move towards a common "long-term vision" for DSpace...or at least start to give us (the Committers) a better sense of what to start to prioritize for the Tech roadmap
[20:34] <tdonohue> BTW -- that Vision Mtg in Chicago is scheduled for May 9-10. I'll be attending on behalf of the Committers (and possibly also Richard Rodgers). It's gonna be around 15 folks of various levels. What will come out of that meeting is just a draft, and I'll get it in front of the Committers right away
[20:35] <tdonohue> just wanted to let you all know the schedule for that... many of you here have someone invited from your institution
[20:36] <tdonohue> (we mostly stuck with inviting folks who also were at the DuraSpace Sponsor Summit, as there was some good background discussion there as well)
[20:37] <mhwood> Thanks, noted.
[20:37] <tdonohue> Ok, in any case, moving along on our agenda.... to the mysterious DSpace 4.0! :)
[20:39] <tdonohue> Despite all these various side discussions (Vision mtg, etc), I still want us to be planning for 4.0 as normal.
[20:39] <tdonohue> Obviously, the big things for 4.0 we need to start thinking about include: what's the schedule look like? who wants to volunteer to be on the release team? what sort of features may we be looking at?
[20:41] <tdonohue> So, with regards to scheduling... I recall our 3.0 schedule ended up with a lot (of pulls) coming in at the last moment
[20:41] <tdonohue> which begs the question...do we have any brainstorms/ideas for improving that? Or do we just "hope folks get stuff in earlier"?
[20:42] <mhwood> I would hope to see the RT asking contributors to "sign up" to aim at specific landing timeframes, somewhat spread out, so that work can be scheduled.
[20:43] * hpottinger notes he's very distracted at the moment and might miss the chance to volunteer for the 4.0 RT, so, consider his hand raised when you ask for release team volunteers.
[20:43] <tdonohue> One "half thought out" idea I had was whether we wanted to have *two* Feature Deadlines... 1) A "Large Feature" deadline - earlier, so we have time to fully review, and 2) A "Small Feature" deadline - which can be a few weeks later as needed.
[20:44] <tdonohue> but, I like mhwood's suggestion too, assuming we can get some "buy in" from contributors to (mostly) stick to a schedule
[20:45] <mhwood> Two deadlines for large and small sound reasonable, but without some more management it also means two pileups instead of one. :-/
[20:47] <tdonohue> mhwood - true, it could. Maybe there's a mixture of our ideas that would work... Contributors who "sign up" to specific landing timeframes...the larger the feature though, the earlier we really need to "see something". Dunno, but I see your point
[20:47] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:48] <mhwood> This is just brainstorming for the RT to consider anyway. They are the ones who have to pull it all together, and will have their own methods in mind.
[20:48] <tdonohue> I was just jumping right to the problem that "large features cannot come in at the last moment" as it delays everything.
[20:48] <tdonohue> yep, agreed about RT can make it's own methods
[20:48] <mhwood> Yes, and large features also require more review time, may have more little problems to iron out....
[20:49] <mhwood> Another thing that might help is regular pleas to "show your work early".
[20:49] <tdonohue> So, regarding the 4.0 Release Team (RT): Anyone else interested? (noted that hpottinger raised hand earlier, thanks Hardy!)
[20:49] <tdonohue> +1 to "show your work early"
[20:50] <tdonohue> (Maybe it's a "show your work by [date]" sort of suggestion/soft-deadline, or else you may not get your work into 4.0)
[20:51] <mhwood> Thinking mainly of "stick it up on github and push frequently, discuss progress regularly"
[20:51] <hpottinger> Also, if your work is small (and "obviously correct"), approve your own PR, it's one way to keep the backlog down, and ensure small changes get tested the rest of the incoming changes
[20:52] <hpottinger> s/rest/along with the rest/
[20:52] <kompewter> hpottinger meant to say: Also, if your work is small (and "obviously correct"), approve your own PR, it's one way to keep the backlog down, and ensure small changes get tested the along with the rest of the incoming changes
[20:52] <tdonohue> mhwood - yea, I agree with that completely. That's the ideal! :) Just noting that sometimes folks decide to "stick it up on github" at the last moment
[20:53] <tdonohue> hpottinger++ also agree we need to trust ourselves more -- approve your PR if it's something obvious. If we really need to, we can always undo it later
[20:54] <mhwood> Ah, that reminds me: some support in finding reviewers would help when the code begins to firm up.
[20:55] <tdonohue> "reviewers" as in PR/code reviewers, I assume? I think the best thing there is to use the Committer Team for that (along with other 'self-selecting' interested developers from the community, if any)
[20:55] <hpottinger> re: reviewers, I hope everyone here knows that we're here to help, if you need a reviewer, ask.
[20:56] <helix84> that's our current bottleneck right there
[20:56] <tdonohue> We can also continue this whole "PR Reviews" at the beginning of IRC mtg (as we did today)
[20:57] <hpottinger> +1 PR Reviews
[20:57] <tdonohue> as that forces us all to look at something for even a brief period
[20:57] <mhwood> Yes
[20:58] <tdonohue> But, I still encourage us all to do reviews at other times as well -- there's no reason to leave it all to these mtgs. If something looks good, help pull it into the codebase, or if you want a second opinion, just ask (in JIRA, dspace-devel, wherever)
[20:59] <tdonohue> Personally, I plan to try and find some time in the next week to actually dig through the JIRA backlog as well, and move "obvious" tickets to the right place... hopefully the more we can do this (for JIRA or PRs), the quicker we can all work to get the "backlog" back under control.
[21:01] <tdonohue> Ok. I still had an outstanding call for 4.0 Release Team members out there :) But, I'll let you all think about it some more as well. Will send a brief email to dspace-commit to ask others too.
[21:02] <tdonohue> Obviously, if anyone is already working on something they are hoping will be ready for 4.0, please feel free to let us know and/or add it to the 4.0 Wiki page: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes
[21:02] <kompewter> [ DSpace Release 4.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes
[21:03] <helix84> I just wanted to say that I don't want to be a RT member this release, because I'll probably be swamped at work at that time. Obviously, I'll still help out, I just don't want to commit myself to it.
[21:04] <hpottinger> we conscripted you last year, helix84, you will not get away so easily ;-)
[21:04] <tdonohue> Beyond that...the final topic on this agenda was 3.2. We still have some "build.properties" tickets open that we wanted to fix in 3.2. We could use some help if anyone has spare time for DS-1528 and DS-1525 (and robint posed a question on DS-1469).
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1528 ] - [#DS-1528] build.properties doesn't support UTF-8 encoding - DuraSpace JIRA
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1525 ] - [#DS-1525] build.properties not interpolated properly when building with Maven 3 - DuraSpace JIRA
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1469 ] - [#DS-1469] Repository name with the accent (dspace.cfg with UTF-8 encoding show incorrect) - DuraSpace JIRA
[21:05] <tdonohue> We don't need to go through these all right now (I know the meeting is in "overtime"). But, I wanted to draw your attention to them in case you have the time
[21:05] <helix84> I probably didn't log it anywhere, but I looked at the second sub-problem twice for a long time and I didn't come up with anything
[21:05] <helix84> of course, I know next to nothing about maven
[21:05] <helix84> ehm, ant
[21:06] <tdonohue> helix84 - are you talking about Ds-1528 (which was split out into a separate ticket), which is a Maven issue?
[21:07] <tdonohue> (Ds-1528 used to be a subproblem of Ds-1469, but we split it out into it's own ticket)
[21:07] <helix84> the original ticket was DS-1469
[21:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1469 ] - [#DS-1469] Repository name with the accent (dspace.cfg with UTF-8 encoding show incorrect) - DuraSpace JIRA
[21:07] <helix84> ok
[21:08] <tdonohue> I'll admit, I played with Ds-1528 too, and it was stumping me as well. It seems like it *should* work, but haven't been able to figure out why it isn't working.
[21:08] <helix84> AFAICT, this is something that maven simply doesn't support at the moment
[21:09] <mhwood> Sorry, all, gotta go, I'm expected elsewhere.
[21:09] <tdonohue> As noted in Ds-1528 though, Maven is *supposed* to support UTF-8 encoding..there's a setting for it in the 'maven-resources-plugin' which reads build.properties. The problem is the setting doesn't seem to work right (or we have something misconfigured)
[21:09] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:09] <helix84> it might be worth filing it as a maven bug, but since then I've forgotten the details
[21:10] * tdonohue notes -- feel free to filter out if you need to. Consider the official meeting adjourned. We're just in "overtime" informal discussion
[21:10] <hpottinger> comment added to 1469, I don't think hard coding to UTF-8 will pose a problem
[21:11] <helix84> what happens if one uses unicode escape sequences (I know one instance who does) and we hardcode it to UTF-8?
[21:12] <helix84> of course, it's no big deal because the breakage would be obvious and easy to fix
[21:13] <tdonohue> Hardcoding doesn't sound horrible. But, if we have concerns we could always do something similar to "mail.charset = UTF-8" ... have a "file.charset = UTF-8"
[21:13] <helix84> tdonohue: that sounds like chicken and egg :)
[21:14] <hpottinger> true, how do you encode *that* config?
[21:14] <tdonohue> duh, you encode it in UTF-8, since it's UTF-8 :) Kidding, yea, I realize that is "chicken and egg" at least for dspace.cfg
[21:15] <helix84> we'd probably just document where it's hardcoded and be done with it
[21:16] <hpottinger> gotta go, boss man wants to talk
[21:16] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:16] <helix84> oh, guys, i wanted to suggest one thing
[21:17] <helix84> i was thinking of "outsourcing" our localization to Translatewiki
[21:17] <tdonohue> "guys" might just be you and I now, helix84. Not sure who else here is "actively listening". But go ahead
[21:17] <helix84> oh
[21:17] <helix84> yeah, i just wanted to know if there are any objections
[21:18] <helix84> i'll probably contact claudia as she's the only one from commiters who cared about l10n in the past
[21:18] <tdonohue> huh, looks interesting. I don't have objections. I just was wondering how it all works (and whether they accept our somewhat odd 'i18n' formats)
[21:19] <helix84> they're really forthcoming, i think they would support our weirdness
[21:19] * linux4u (~james@employed.library.emory.edu) Quit (Read error: Connection reset by peer)
[21:19] <tdonohue> I think we all "care"...it's just that claudia is the expert. I'd love to find ways to improve translations / i18n in DSpace in general. I know it's a frustration for many...but, I'm just not an expert in that area
[21:20] <helix84> but there are other possible approaches opening up so maybe it would be wise to wait until the first feature deadlines
[21:20] <tdonohue> I think many of the other committers (at least those of us who really only know one language) are in that same boat. We want to see things improve, but we don't know what the latest "best practices" or ideas are
[21:20] <helix84> so, nevermind, just thinking aloud
[21:21] <helix84> honestly, what we have in DSpace in terms of i18n (not l10n) might about be the worst I've seen in FLOSS
[21:21] <helix84> but we've known that for some time now
[21:22] <helix84> so there's no other way but up :)
[21:23] <tdonohue> Yea, unfortunately I think we have known that. I think the "roadblock" in some ways is "we aren't sure how to improve it quickly" and "Cocoon in some ways seems to be 'in the way' of things"
[21:24] <tdonohue> But, I think most everyone would *love it* if a small group/individual came up with an idea of how to do i18n better and just ran with it.
[21:24] <helix84> i'll take you up on that
[21:25] <helix84> just know that it will hurt a bit (only the developers)
[21:25] <tdonohue> seriously, do take me up on that. It's what we talked about a bit in last week's IRC mtg (not sure if you were there) -- we all want to find ways to "empower" small teams/individuals to just "run with something" and stop waiting around for "official votes", widespread consensus (which is very difficult and takes forever)
[21:26] <helix84> i've read today's log after I came late - what was that Chicago thing?
[21:26] <tdonohue> I'm fine with it hurting the developers a bit, as long as we can come up with a decent way to "tackle" it all so that migrations/upgrades aren't that big a deal. I'd be willing to chip in on code if that's what is needed (I'd just need to be told what to do)
[21:27] <tdonohue> nope. The "empowerment" discussion was actually just a random discussion in IRC last week. It's also something we plan to discuss more at OR13 - see the possible agenda topics for that mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting#DevMtg2013-07-08-OR13Meeting-PossibleAgendaDiscussionTopics
[21:27] <kompewter> [ DevMtg 2013-07-08 - OR13 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-08+-+OR13+Meeting#DevMtg2013-07-08-OR13Meeting-PossibleAgendaDiscussionTopics
[21:28] <helix84> if you want to chip in on code, here's where you can start playing and giving opinion: https://github.com/lyncode/xliff-translate
[21:28] <kompewter> [ lyncode/xliff-translate · GitHub ] - https://github.com/lyncode/xliff-translate
[21:29] <tdonohue> The "Chicago Mtg" is the "Draft a 3-5 year vision/high-level roadmap for Dspace" meeting. It's a small group meeting to do a first draft, which will then be widely distributed for comments/feedback/improvement
[21:29] <helix84> oh, it's that meeting with the sponsors and the Futures participants, right?
[21:30] <tdonohue> yes, it's that meeting. It's coming up in May. Will be about 15 people. Output of it will be a "draft" of a high-level vision/roadmap for DSpace.
[21:30] <helix84> thanks
[21:30] <tdonohue> no problem.
[21:31] <tdonohue> So, is XLIFF a widely used format? Just curious if there's many "translation tools" built which support XLIFF (assuming so)
[21:32] <helix84> gettext is the most widely used in OSS. but Java isn't friends with that, we already talked about that. XLIFF is a newer thing and can do everything that gettext can do. there don't seem to be any good Java libraries for that, either, so Joao did a small experiment to build one.
[21:33] <helix84> support of XLIFF in translation tools is quite good and should be only getting better
[21:33] <tdonohue> ok, makes sense. yea, was just reading up on XLIFF on wikipedia: http://en.wikipedia.org/wiki/XLIFF
[21:33] <kompewter> [ XLIFF - Wikipedia, the free encyclopedia ] - http://en.wikipedia.org/wiki/XLIFF
[21:33] <helix84> at this time it's the second best thing after gettext (IMHO)
[21:34] <tdonohue> yea, and I like that there are actual *editors* which can be used with XLIFF. (unlike our strange Cocoon-based XML format)
[21:34] <tdonohue> my only concern would be "Can we can XLIFF to play well with Cocoon"
[21:34] <tdonohue> (and I hope the answer will be "yes")
[21:35] <helix84> there might be an intermediate conversion step or someone might write a Cocoon Transformer
[21:35] <helix84> either is fine by me
[21:36] <helix84> the conversion step would be an XSLT. i don't know anyone who is able to write the transformer.
[21:37] <tdonohue> we could probably find someone to write a transformer for Cocoon...if not, XSLT could work
[21:38] <helix84> turning the page, do you remember our commiter recruitment idea after which we chose Bram?
[21:38] <tdonohue> It should just be a matter of rewriting the default Cocoon i18Transformer to use the XLIFF API. I'm hoping that wouldn't be too overly hard.
[21:38] <helix84> we might want to do another round
[21:39] <helix84> tdonohue: I'm glad it sounds easy. Every time I tried even building our modified Cocoon myself I failed miserably.
[21:39] <tdonohue> sounds fine to me. Honestly, I've been trying to make sure all Committers know they can bring up "committer recruitment" or suggest possible new committers at any time.
[21:40] <tdonohue> I didn't say it sounds "easy" :) I just hope it wouldn't be too overly hard (we're already customizing Cocoon a small bit with our https://github.com/DSpace/dspace-cocoon-servlet-service-impl
[21:40] <kompewter> [ DSpace/dspace-cocoon-servlet-service-impl · GitHub ] - https://github.com/DSpace/dspace-cocoon-servlet-service-impl
[21:40] <helix84> there are so many people doing cool things with DSpace and they are not "at the source", distributing their stuff - that makes me sad
[21:41] <tdonohue> honestly, suggest a few. I'd love to add some new committers into the mix.
[21:41] <helix84> also, we have many patches sitting in Jira and we just don't get around to review them all properly
[21:42] * tdonohue has to leave shortly, unfortunately
[21:42] <helix84> apart from our last candidates (who I still support), I think we forgot to mention Nestor Oviedo
[21:43] <tdonohue> we should discuss on -commit obviously. :)
[21:44] <helix84> sure, see you later
[21:50] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Quit: helix84)
[21:52] * sudobear (~sudobear@leikung.grainger.uiuc.edu) Quit (Remote host closed the connection)
[21:54] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:26] * PeterDie_ (~peterdiet@128.146.173.70) has joined #duraspace
[22:27] * PeterDietz (~peterdiet@128.146.173.70) Quit (Ping timeout: 264 seconds)
[23:11] * fasseg (~ruckus@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Ex-Chat)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.