Timestamps are in GMT/BST.
[3:51] * misilot (~misilot@p-body.lib.fit.edu) Quit (*.net *.split)
[3:53] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[6:55] -holmes.freenode.net- *** Looking up your hostname...
[6:55] -holmes.freenode.net- *** Checking Ident
[6:55] -holmes.freenode.net- *** Found your hostname
[6:55] -holmes.freenode.net- *** No Ident response
[6:55] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:55] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:55] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:57] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[10:31] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[10:32] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[12:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:26] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[17:17] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[18:29] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:10] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:34] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Ping timeout: 264 seconds)
[19:42] * helix84_ (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:00] <tdonohue> Hi all, time for our weekly DSpace Devel Mtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-06-19
[20:00] <kompewter> [ DevMtg 2013-06-19 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-06-19
[20:01] <tdonohue> We'll kick off with a few PR reviews: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <tdonohue> today, starting at #190: https://github.com/DSpace/DSpace/pull/190
[20:01] <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:01] <tdonohue> related to DS-1493
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1493 ] - [#DS-1493] Sharing and Export Bar - DuraSpace JIRA
[20:02] <PeterDietz> I would say the export to endnote et all, is a definite win. We have the share-bar on ours, I haven't heard of any praise about it
[20:03] <helix84_> this is the dspace-api implementation and JSPUI interface, XMLUI interface is a separate ticket
[20:03] <tdonohue> ok, was wondering if there was a separate one for XMLUI
[20:04] <PeterDietz> the export/crosswalk uses the XOAI to translate?? I'm a bit confused by that one
[20:04] <tdonohue> This seems reasonable. Just wondering (like PeterDietz implies) if these sorts of "share-bars" still get much use/excitement
[20:05] <mhwood> I've never used one, but I'm probably not a good model.
[20:05] <helix84_> seems so, e.g. dspace/config/crosswalks/export/bibtex.xsl
[20:05] <tdonohue> I never have used one either. Just not sure if anyone else has had their users asking for this feature, or implemented it locally
[20:06] <tdonohue> So, if this depends on XOAI, it sounds like it'd also need to be able to be disabled. As it'll break if you don't want to run XOAI
[20:06] <helix84_> I did occasionally use things like RIS export on other platforms. So although this may not be for everyday use, I definitely see the benefits of having it.
[20:07] <mhwood> Haven't had time to thoroughly examine the code, but wondering if this is two features.
[20:08] <helix84_> mhwood: what two features do you mean?
[20:08] <tdonohue> it seems like two (related) features...has two configs: "sharingbar.cfg" and "export.cfg"
[20:08] <mhwood> "Social Sharing Bar" and "Citation Export".
[20:09] <helix84_> right, seems so. would that be a problem?
[20:09] <mhwood> There may not be enough factoring available to be worth the effort. Just musing.
[20:09] <tdonohue> though, it looks like from the screenshot (attached to DS-1493), it's all in one "bar"
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1493 ] - [#DS-1493] Sharing and Export Bar - DuraSpace JIRA
[20:10] <tdonohue> more info: https://wiki.duraspace.org/display/~joaomelo/Sharing+and+Export+Bar
[20:10] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~joaomelo/Sharing+and+Export+Bar
[20:11] <tdonohue> It seems like a fine addition. I just would wonder whether some minor cleanup is in order: (1) Should one be able to *disable* it, if they don't want it, (2) Does it really need two separate config files? Why not one config?
[20:11] <PeterDietz> I guess to enable this is up to the end-user repo, they seem like fine/worth-while features to have. I'm just wondering if they are implemented correctly.. Configs in modules (check), crosswalk using crosswalk (check)...
[20:11] <mhwood> I do think maybe this shows that there is something in XOAI that needs to come out, if it's more generally useful.
[20:12] * helix84_ (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Quit: helix84_)
[20:12] <tdonohue> finally -- how does this relate to the other recent "citation export" tools (in 3.0)...should those get "tied in" with this bar somehow eventually
[20:12] <PeterDietz> The "code smell" to me, is how much Java was involved to make a share-bar. To me, this is all client-side JS, with a bit of configs to load
[20:13] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:13] <tdonohue> PeterDietz -- for the sharebar part, yes. But, for the *export* piece, you'd need Java to do the export translation
[20:13] <helix84> xoai is XSLT based
[20:13] <helix84> BTE is not limited to XSLT
[20:14] <tdonohue> right right. since it's plugged up via XOAI it can do this via XSLT. Just pointing out that part of this work needs to be done server-side...the other part can be client-side like Peter says
[20:15] <tdonohue> OK. So, sounds like the consensus may be: Seems OK. Some questions here (mostly me) about whether it should be able to be disabled...or if it really needs multiple config files to manage it
[20:16] <tdonohue> Would be also nice to see an XMLUI version get built too
[20:16] <mhwood> And whether it should be possible to disable one side but not the other.
[20:16] <helix84> I don't mean to derail the train here, but it sounds like a recurring general issue - since we have JSPUI and several XMLUI themes, there are often javascript/css thingies that should be reused across them. we currently don't do that.
[20:16] <helix84> tdonohue: Joao is exploring building XMLUI aspects, he's interested in porting this sharing bar to XMLUI
[20:16] * [1]KevinVdV (~Kevin@d5153D041.access.telenet.be) has joined #duraspace
[20:17] <tdonohue> helix84: Ok, wasn't clear (not mentioned anywhere) that he's looking at an XMLUI version
[20:18] <tdonohue> As for shared JS/CSS. Shared CSS is HARD (depends on the HTML so much). Shared JS is more plausable...but still may not always work right in multiple UIs (again can be HTML dependent, based on what that JS is trying to do)
[20:18] <tdonohue> but *sharing* common JS/CS tools/ideas (e.g. Use JQuery) is a good thing
[20:19] <tdonohue> Not really sure we can force UIs to do much more than that...it's just too much to try to support between two entirely different UIs (and many themes)
[20:19] <mhwood> Maybe there is enough sharing available to start a "common webapp support" project.
[20:19] <helix84> mhwood: you got me interested. care to elaborate?
[20:19] <tdonohue> if there's enough to share, sure. Just not certain there is enough in common to share
[20:20] <mhwood> Well, if there are sizable things which are simply repeated or reimplemented then they could be factored out and the JSPUI and XMLUI (etc) made dependent on them.
[20:20] <helix84> off the top of my head: search completion, authority/controlled vocabulary completion, citation generation, sharing
[20:21] <helix84> community/collection hierarchy collapsing
[20:21] <mhwood> Once there is a place to put this stuff, then we need the habit of asking, "is this bit of UI plumbing readily generalized, or do I have to make it UI-specific?"
[20:22] <mhwood> Kind of like dspace-api, only for webapp stuff instead of business-logic stuff.
[20:22] <tdonohue> helix84: if each of those could be "extracted" as little JS widgets, then yea it'd be nice to see if we could share them across the UIs. I'm just wondering (in my mind) how much work/effort that'd take
[20:23] <mhwood> I have no idea whether there is enough to gain, to be worth the effort.
[20:23] <helix84> tdonohue: the implementation effort would be offset by easier maintenance and feature parity between interfaces. of course, it's a big Volunteer Needed.
[20:23] <tdonohue> So, I like the ideas here. Just wondering out loud how much work it would be (I honestly don't know...maybe it's easy enough)
[20:23] <PeterDietz> I'm weighing on the side of making each UI, separate stand-alone projects/modules. Put repeated data-model level logic into the services layer.
[20:23] <mhwood> Someone can pick a feature and try to factor it out. Then we'll know.
[20:24] <helix84> PeterDietz: yes, but these are mostly client-side things
[20:25] <tdonohue> This almost starts to sound like another sort of "addon" or "plugin". We usually talk about server-side "plugins" to DSpace (how do we plugin this bit of Java/XSLT stuff). This starts to sound like a client-side "plugin" (How do I plugin this little JS Widget into my DSpace, whether I'm running JSPUI or XMLUI)
[20:25] <hpottinger> so, it sounds like we need a JS framework to work with our pending Business Logic Layer?
[20:26] <mhwood> Like jQuery only DSpace-specific.
[20:26] <tdonohue> mhwood: not necessarily.
[20:26] <helix84> the problem here is not so much where the widget would live, but to coordinate the HTML it depends on across interfaces
[20:27] <tdonohue> I was more thinking: Here's a JQuery "widget" that happens to work for DSpace...it will do Auto-complete in your DSpace, or whatever. The big limitation here is we still don't have a REST API (there, I said it again) ;)
[20:27] <hpottinger> We certainly could do with some organization of all the JS bits, there is a bunch in the box, but figuring out which bit you've broken when you try to add your own is a daunting task
[20:28] <hpottinger> Not that I ever break anything, ever, mind you
[20:28] <tdonohue> yea, I still don't know if this is a "doable" thing. Trying to sync up / coordinate the HTML to the level that you don't accidentally break a JS widget could be too hard
[20:29] <tdonohue> Plus, there's the question of... do we really want to centrally support multiple UIs forever and ever.
[20:29] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Read error: Connection reset by peer)
[20:29] <tdonohue> (not implying anything by that...just reminding that we are continually asking why are we supporting *multiple* versions/implemenations of things. That also needs to apply to the UI)
[20:30] <tdonohue> In any case, I feel like this conversation has run it's course. Not sure there's anything actionable *yet*. But if someone wanted to do some digging/research there is a general "brainstorm" out there
[20:31] <tdonohue> So, moving along. The next topic for today.. Revisiting 3.2 release
[20:31] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:32] <tdonohue> I think it's become obvious (to Committers at least) that we'll need to do a 3.2 release, cause of the recent minor JSPUI security issue (As this is a logged channel, not gonna say anything beyond that, until we have a patch)
[20:33] <mhwood> Yes.
[20:33] <tdonohue> I think the questions that remain are: When? and is there any other last little fixes we want to add to 3.2?
[20:33] <helix84> as I see it, we should release all other fixes that are ready by that time along with it as 3.2
[20:34] <tdonohue> helix84 : yea, by default that's my stance too. It's sorta an "anything that is ready" by the time the security fix is in.
[20:34] <helix84> I've been commiting all that's ready to the 3_x branch
[20:34] <[1]KevinVdV> Just fired a new one, if anybody is up for it: https://github.com/DSpace/DSpace/pull/239
[20:34] <kompewter> [ [DS-1489] SolrJ-3.3.0 dependency in OAI by KevinVdV · Pull Request #239 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/239
[20:35] <helix84> the bugslayer is back!
[20:35] <helix84> hail the bugslayer!
[20:35] <mhwood> Looks good.
[20:35] <tdonohue> So, is any more help/feedback needed on the JSPUI security fix? (Please don't get too specific yet, no links, etc. -- again, we want to tread carefully on a logged/indexed channel until we can get the fixes to our community)
[20:36] <helix84> yes. which older version do we still consider subject to security fixes?
[20:36] <helix84> three years back? more?
[20:36] <hpottinger> good question, helix84
[20:37] <tdonohue> I think that is something for us to decide. Admittedly, this is the first time we've had to tackle such an issue (at least since I've been the "tech lead" and that I can recall).
[20:37] <hpottinger> tdonohue, help/feedback needed, I'm unable to implement the change the Kostas suggested
[20:37] <tdonohue> My gut says we push out a fix for 1.8.x and 1.7.x. But, further back than that, I think we just provide a fix/patch and they are "on their own".
[20:37] <tdonohue> But, I'm open to suggestions too
[20:38] <helix84> tdonohue: sounds reasonable to me
[20:38] <[1]KevinVdV> I agree
[20:38] <hpottinger> 1.7 and 1.8 should be do-able, and I doubt the design of that object has changed much, probably we could go back farther, maybe try patching until the patch fails?
[20:38] <mhwood> Wait until someone with an older version says, "hey, what about us?"
[20:38] <tdonohue> for reference: 1.7.0 was released in Dec 2010.
[20:39] <hpottinger> do we have a policy already?
[20:39] <tdonohue> I'm wondering if in general we just make it policy that "We only support the last 3 major releases in terms of security patches".
[20:39] <mhwood> tdonohue++
[20:39] <tdonohue> we don't have an official policy yet, no.
[20:40] <tdonohue> I'm suggesting though that we create one. We can vote on it on dspace-commit (I'll send an email to all committers later today/tomorrow), if the "last 3 major releases" sounds reasonable
[20:41] <mhwood> That's what Tomcat does. Enough precedent for me.
[20:42] <hpottinger> last 3 major tagged releases sounds fine to me, I wonder what it will be like to release those old versions?
[20:42] <hpottinger> we did just migrate from SVN to Github last year.
[20:43] <tdonohue> yuck. Hmm...that's right. 1.7.x and 1.8.x will have old POMs based on SVN
[20:43] * helix84_ (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:43] <helix84_> yea, I'd say 3 years is pretty standard in open source. RHEL is the only one that comes to mind that goes way beyond that (with smallprint).
[20:44] <helix84_> I wanted to say that we should declare a policy on security support. that will give our users an idea how far back they can afford to lag behind the latest release.
[20:44] <tdonohue> well, I suspect it may take a bit of "work" to release a 1.7.x and a 1.8.x, but that work should mainly be updates to the POM to support Git/GitHub. I'd be glad to help with that process. We still have the 1.7.x & 1.8.x branches though, which is good
[20:44] * mhwood mumbles something about RHEL never being *less* than 3 years backlevel....
[20:44] <hpottinger> I'm game to try the older releases, but it's bound to get a bit soupy, I'll probably need help
[20:44] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Ping timeout: 256 seconds)
[20:45] <tdonohue> hpottinger: I guarrantee it won't work until we update the POMs. I'm *hoping* it should mostly be a "backporting" of the Git/GitHub POM changes from 3.x to 1.8.x & 1.7.x
[20:46] <mhwood> That should not be a really big problem.
[20:46] <tdonohue> no, it seems doable. Just is an extra step
[20:47] <hpottinger> I just remember trying to do something similar on my own for 1.7, and finally throwing in the towel and just leaving my 1.7 tree in Subversion :-\
[20:48] <tdonohue> So, I think the next steps are: (1) Get hpottinger the feedback he needs to finalize the patch (on dspace-commit). (2) Cleanup 1.7.x & 1.8.x branches to work for GitHub. (3) Commit patch to all three, release 3.2, 1.8.3 and 1.7.3. (4) Announce security release to community & provide a patch for older releases
[20:49] <tdonohue> (And simultaneously, I'll start up a vote on our policies around security fixes on dspace-commit. That way we can clarify/announce these policies as part of the community announcement)
[20:50] <helix84_> (3.5) get Relase Notes ready for all the patched versions
[20:50] <mhwood> Clarify/announce/document, so we can go see what our policy is 6 months from now.
[20:50] <tdonohue> mhwood++ very true
[20:50] <tdonohue> helix84_ yep, true as well
[20:51] <tdonohue> So: there's a lot of (smallish) tasks here. Do we have folks willing to chip in? (Either let us know now, or on dspace-commit)
[20:51] <helix84_> question: does anyone mind if I throw in some more bugfixes to 1.8.3?
[20:52] <tdonohue> For myself, I'm happy to help with #2 (GitHub POM cleanup) and #4. Not sure how much time though I'll have for others...would be good to get more hands on deck here, if folks have time
[20:52] <tdonohue> Ideally, we really should get this all done soonish (by end of next week)
[20:53] <tdonohue> helix84_ : cause of tight timelines here, I'd actually rather not. I don't want to cause delays
[20:53] <helix84_> understood
[20:54] <tdonohue> Perhaps that's also a part of our (soon to be) policy. How many versions back do we really want to support bug-fixes as well
[20:54] <helix84_> if you want to organize a "securitathon" on #dspace before next wednesday, I'll try to come and help
[20:56] <tdonohue> we could try for a "securitathon"..though my schedule is tighter and tighter these days (with OR looming, my time is harder to come by)
[20:57] <tdonohue> I do suggest though that it'd be nice if we all can take a few moments to provide feedback on dspace-commit on the proposed changes.
[20:58] <tdonohue> I'll promise to do the same
[20:59] <hpottinger> end of next week is June 28
[21:00] <tdonohue> yes. Ideally, in my mind, we work to get this all resolved so that we can do the releases on/around June 26th/27th and announce on June 27th/28th. If it gets done sooner, great. Just some dates to shoot for.
[21:02] <tdonohue> As we are now at 1 hr, I'm not gonna call any more agenda items. But, I will mention, for anyone going to OR13: If you have ever been to PEI and know of any good pubs in the area, let me know. Looking for a place we can all go after the face-to-face Devel Mtg. I'm gonna ask around elsewhere as well. Just thought I'd mention it here.
[21:03] <tdonohue> beyond that, the meeting is essentially adjourned. I'll stick around here if anyone has anything else to discuss. But, no more official agenda items for today
[21:03] <helix84_> This will be my first time at an OR event and I'm overwhelmed by the choices of presentations. Do you have a personal plan yet? Any recommendations?
[21:04] <hpottinger> helix84_ Bram usually puts together a "must see" list
[21:05] <tdonohue> admittedly, I haven't even had a chance to look at the array of presentations :) I have too much to prepare to present/organize myself! Though I do need to decide what to do on Monday morning (before our DSpace Devel Mtg starts)
[21:06] <hpottinger> Oh, speaking of this, my presentation is on "yay, DSpace 3.1" I'd like to hear from anyone who is running 3.1 in production.
[21:06] <tdonohue> OR does usually have so much going on that it can be hard to decide what to attend. It's a pretty busy conference, but I also find it to be my most enjoyable of the year
[21:08] <tdonohue> hpottinger: DSpaceDirect is hosting several 3.1 (unadvertised) production instances...but we don't have anything official to announce just *yet* (But hope to have a few we can show in time for OR13, though content will still likely be minimal so it may not be much to show)
[21:09] <hpottinger> my tactic is usually to plot a path through the things that I *need* to know more about, to help me do my job, connecting those dots usually puts me in interesting places. And then, if I have some flexibility, I follow other DSpace folks around to check out whatever they're checking out.
[21:09] <tdonohue> I vaguely recall other committers saying they are moving to 3.1 "soonish". But, not sure if anyone has yet?
[21:09] <[1]KevinVdV> Need to run, until next time
[21:09] <mhwood> I have to go too. 'bye!
[21:10] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:10] <hpottinger> tdonohue, I'll happily give you guys a free plug during my talk, send me screenshots
[21:10] <helix84_> hpottinger: my experiences from the lists say that there's an often occurring problem with OAI that gives you a "no matches found" error when you have a non-GMT timezone set. a big bummer because Joao wasn't able to fix it properly yet.
[21:10] * [1]KevinVdV (~Kevin@d5153D041.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- \o/)
[21:10] <helix84_> i have 3.1 in production
[21:11] <hpottinger> I'll repeat this on the dspace_tech list, but anyone with a 3.1 "war story" to tell, or screenshots you're particularly proud of, send 'em my way
[21:12] <hpottinger> I plan to spend at least part of my talk admonishing folks to please patch to at least their latest incremental release
[21:12] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[21:12] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Client Quit)
[21:13] <helix84_> i personally don't remember anything particularly hard about 1.8->3, but that may be just because I ran master in a testing environment for a long time :p
[21:14] <helix84_> I did a presentation on what's new in DSpace 3, but the slides are just bullet points, mostly the same as release notes
[21:15] <hpottinger> I went from 1.7 to 3.1, majority of my time was spent on updating theme code (we switched to a new theme, but it was 1.8-based, and somewhat complex)
[21:15] <helix84_> the meat was how the new OAI is awesome and that JSPUI now can have Discovery plus a dozen small improvements
[21:15] <hpottinger> My abstract for my talk, in keeping with the theme of the conference (re-use) was a mere cut/paste of release notes pages from the wiki :-)
[21:16] <hpottinger> I intend to sing the praises of the new build.properties and ENV.properties files
[21:17] <helix84_> I still have nightmares of the breakage it caused
[21:17] * helix84_ shudders
[21:18] <hpottinger> I've gone on and on about the properties file, it's hands down my favorite part about 3.x
[21:19] <helix84_> the only reason why it's useless for me is that it allows only a small subset of properties
[21:20] <helix84_> but I'm looking forward to the idea of dynamic configurations (whether file or DB-based)
[21:20] <tdonohue> well, you can always "extend" it to add more of the properties you want (assuming it's still a subset of the total number of properties) :)
[21:21] <helix84_> that defeats its point with regard to having a clean checkout
[21:22] <helix84_> if i have to apply an extra patch, it can be my configuration changes, not a change to store my configuration changes separately
[21:22] <tdonohue> DSpaceDirect depends heavily on the properties files for initial installation/setup...which makes me think they are awesome too. But, after that initial setup/install, there are times we do (obviously) need to dig into other configs.
[21:23] <tdonohue> the whole benefit though of the properties (in my opinion), is it allows you to get a "quickstart" DSpace up and running (with minimal property tweaks), and then worry about the whole world of options later on
[21:23] <tdonohue> (which is essentially the exact way it is used for DSpaceDirect)
[21:24] <hpottinger> My favorite part is that you can take a brand new clone of DSpace, or just the zip download from source forge, drop one file in the root folder, and BAM you're off and running
[21:24] <helix84_> apropos, if anyone wants to nominate Sam, please go ahead. I've done my share of nominations lately :)
[21:24] <tdonohue> but, I agree that I look forward to dynamic configurations as well eventually
[21:26] <helix84_> a word of advice - I think it was worth reaching out to the nominee first and measuring their interest/availability
[21:30] <helix84_> hpottinger: anything in particular you wanted to ask about 3.x in production
[21:32] <hpottinger> helix84_, I need stories and pictures, favorite features and why, pain points and how you dealt with them (I intend to share what we elected to punt on implementing, but still intend to implement).
[21:35] <helix84_> what did you decide to postpone implementing?
[21:35] <hpottinger> man, if I spill the beans now, you'll skip my session
[21:36] <helix84_> I think I still had to for some reason. But I'll surely catch up on the videos.
[21:37] <hpottinger> don't worry, if my reputation precedes me, I assure you: no dancing
[21:37] <helix84_> I hope no running, either
[21:38] <hpottinger> you *might* be able to con me into doing a yo-yo trick, though
[21:38] <helix84_> favourite feature - OAI, hands down. Speed, Driver and OpenAIRE support out-of-the box, unprecedented ease of customization via XSL.
[21:39] * tdonohue begins drafting a tweet: "Really looking forward to hpottinger's 'DSpace 3.1' talk at OR13! Promises to feature dancing & yo-yo tricks!"
[21:39] <helix84_> pain point - not mine, personally, but one may decide to finally shed the old Reference theme and build a new Mirage-based theme properly using xsl:import and template overlays + mention why this will save you time and effort on future theme upgrades (you may say what a bother they are)
[21:40] <helix84_> oh, yeah - favourite disappointments:
[21:40] <helix84_> query autocompletion stopped working in XSMLUI
[21:40] <tdonohue> that's a pain point not specific to 3.x though :) But, I still agree with your point
[21:41] <hpottinger> erm, no, no dancing, unconditional yes to yo-yo trick, though
[21:41] <helix84_> More Like This never worked until 3.1 and even so doesn't work so well, especially if you try to tweak its configuration
[21:42] <helix84_> caveat to those using XMLUI+Discovery: access-rights aware display is on by default, which means you won't see in search results what you can't access!
[21:42] <helix84_> that's a problem because you might find something in anonymous mode and decide to log in to get access
[21:43] <helix84_> I'm not intentionaly going in the direction of what I don't like, it just slides off of my tongue on its own... :(
[21:43] <tdonohue> the other "spin" on that caveat is that it's nice to no longer get results to things you cannot access. But it does meant to get full results, you need to login first
[21:44] <tdonohue> (i.e. I can see both opinions on that "access-rights aware" option. Some may like it, some may not. It is worth noting it is on by default though)
[21:44] <helix84_> there was a solution I suggested, which wasn't implemented - add it to the new search results options menu and let the user decide
[21:44] <hpottinger> I wonder if I could have an open mic, "favorite feature" vs. "biggest gripe" session?
[21:45] <helix84_> I'm actually mic-shy
[21:45] <tdonohue> possibly, though that could get a bit "out of hand", if say helix84 steals the mic ;) (Kidding)
[21:46] <helix84_> the only chance of me staling the mic is to hide it
[21:48] <hpottinger> nah, helix84_ can be trusted
[21:48] <hpottinger> I'd hazard to say anyone in our community can be trusted, honestly
[21:49] <helix84_> may I hold your wallet for a while?
[21:49] <hpottinger> sure, it's empty
[21:49] <helix84_> I forgot, you're married
[21:49] <hpottinger> I'm quite fond of it, though, it's made of Tyvek
[21:51] <helix84_> hpottinger: look at PM
[21:53] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:08] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:08] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 264 seconds)
[22:09] * helix84_ (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[22:11] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.