Timestamps are in GMT/BST.
[0:00] <ValorieHollister> Are there any DSpace Ambassadors on the chat?
[0:18] * Zico (~7b312e8f@gateway/web/freenode/x-qesckzbmmerriaum) has joined #duraspace
[0:18] <Zico> hi
[0:18] <Zico> hello all
[0:18] <Zico> sorry for little bit late
[0:18] <Zico> traffic!!! :(
[0:20] <ValorieHollister> Hi Zico! I think it is just you and me.
[0:21] <ValorieHollister> Have you had anyone contact you because of your role as a DSpace Ambassador?
[0:28] <Zico> yea
[0:29] <Zico> actually many universities and instituitions are trying to implement dspace in their organization
[0:29] <Zico> and... they contacted me
[0:29] <Zico> but.. i don`t think that... it`s for my "Ambassador" role
[0:30] <Zico> actually.. what i think... they know me from before as our university is the *one* who implemented DSpace *perfectly* in whole Bangladesh
[0:30] <ValorieHollister> more because of your current projects/affiliations?
[0:31] <ValorieHollister> how do they hear about you? has there been some promotion or presentation at a conference?
[0:34] <Zico> umm
[0:35] <Zico> actually yea
[0:35] <Zico> when we implemented dspace in our university, we organized a launching ceremony
[0:36] <Zico> plus... i took a 3 day technical workshop in South-East University of Dhaka on "DSpace: it`s implementatin and prospect"
[0:36] <Zico> that`s how they know me
[0:37] <ValorieHollister> did you do much customization to your repository?
[1:01] <Zico> Sorry Valorie, i had to go for my boss`s call
[1:01] <Zico> not that much
[1:01] <ValorieHollister> Zico, my apologies, but I must sign off. It was nice chatting with you. If you have anything to add -- including your opinion on whether or not we should hold regular mtgs please let me know.
[1:01] <Zico> but... header, footer, news
[1:01] <Zico> Communities and Collections and others
[1:02] <ValorieHollister> I'll be sending out a link to the notes.
[1:02] <Zico> yes, i think, the meetings should be more frequent
[1:02] <Zico> but, why the people are absent ??
[1:02] <ValorieHollister> I'm not sure. What is your local time?
[1:03] <Zico> now... it`s 12:05 pm Dhaka, Bangladesh
[1:03] <Zico> it was 11 am
[1:05] <ValorieHollister> We don't have that many ambassadors from Asia -- but the attendence has been light on the mtgs today. We have close to 30 ambassadors and I think only 8 (including you) attended a mtg.
[1:07] <ValorieHollister> We can discuss it on the ambassador google group -- see if there is feedback on mtgs.
[1:07] <ValorieHollister> I need to head to bed -- it is after 1am my time. Good night -- and thanks for joining the mtg!
[1:08] * Zico (~7b312e8f@gateway/web/freenode/x-qesckzbmmerriaum) Quit (Ping timeout: 252 seconds)
[1:08] * ValorieHollister (~440e1e7e@gateway/web/freenode/x-uvcpesursahznxtx) Quit (Quit: Page closed)
[1:10] * Zico (~7b312e8f@gateway/web/freenode/x-dyjdbvvhvaxhvkvs) has joined #duraspace
[1:10] <Zico> who is the ambassador here?
[1:10] <Zico> from any country?
[1:21] * Zico (~7b312e8f@gateway/web/freenode/x-dyjdbvvhvaxhvkvs) Quit (Quit: Page closed)
[2:09] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[2:12] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[4:05] -hubbard.freenode.net- *** Looking up your hostname...
[4:05] -hubbard.freenode.net- *** Checking Ident
[4:05] -hubbard.freenode.net- *** Found your hostname
[4:05] -hubbard.freenode.net- *** No Ident response
[4:05] [frigg VERSION]
[4:05] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:05] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:05] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:05] -hubbard.freenode.net- [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
[5:33] * quoll (~quoll@c-98-249-18-172.hsd1.va.comcast.net) Quit (*.net *.split)
[7:19] * awoods (~awoods@pool-72-66-75-45.washdc.fios.verizon.net) has joined #duraspace
[8:10] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[8:12] * ClaudiaJuergen (~Miranda@pc5102.ub.uni-dortmund.de) has joined #duraspace
[9:29] * ClaudiaJuergen (~Miranda@pc5102.ub.uni-dortmund.de) Quit (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
[9:34] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[10:24] * Dan_Davis (~43f11873@gateway/web/freenode/x-ltibsswgplrorkbu) Quit (Quit: Page closed)
[11:25] * alidigitalis_ (~chatzilla@va-67-233-102-229.sta.embarqhsd.net) has joined #duraspace
[11:26] * alidigitalis (~chatzilla@va-67-233-102-229.sta.embarqhsd.net) Quit (Ping timeout: 240 seconds)
[11:26] * alidigitalis_ is now known as alidigitalis
[14:40] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[14:56] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[14:58] * cccharles (~user@131.104.62.47) has joined #duraspace
[14:58] <tdonohue> Hi all, we'll be starting the DSpace Developers Mtg here in just a few minutes. I sent an agenda across dspace-devel: https://sourceforge.net/mailarchive/forum.php?thread_name=4B7C0DA3.7010109%40duraspace.org&forum_name=dspace-devel
[15:01] <tdonohue> Ok, it looks like most folks have made there way here. I believe stuartlewis is traveling, so he likely won't be here. So, we can go ahead and get started with a Testathon update, etc.
[15:03] <tdonohue> Latest update from Testathon -- I haven't heard much from folks testing, but there have been very few bugs entered into Jira this week (and all that I've seen look minor). I'm hoping to set aside a large part of this meeting to catchup on Jira, and look at these bugs, etc
[15:04] <tdonohue> So, I'm assuming we still look to be good to release 1.6.0 on March 1 or 2 -- assuming we don't come across anything serious in the remaining testing
[15:04] <tdonohue> (but, speak up if you disagree!)
[15:04] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:05] <tdonohue> That also brings me to another comment. I'd appreciate it if the committers could take a lead on tackling any small bugs that have come in... Both Stuart & I will unfortunately be out of town all of next week, so we likely won't be in #dspace, but are available via email
[15:07] <tdonohue> And, I'd like to suggest canceling next weeks Dev meeting, as many of us will be at either dev8D or code4lib. However, if any of you still want to meet, feel free.
[15:07] <tdonohue> is anyone opposed to canceling next week?
[15:09] <tdonohue> because of these upcoming conferences, our release schedule is obviously a bit tight...I'm hoping to do the "Final freeze" on March 1 around 15:00 UTC (I'll send this out via email as well after this meeting). If any serious issues come up before then, we'll obviously push that back (but hopefully nothing will)
[15:10] <tdonohue> Anyone have comments/questions about the upcoming release schedule, etc.? or does this sound good (send me a +1 if you are onboard)?
[15:11] <mhwood> +1
[15:11] <PeterDietz> +1
[15:11] <keithg> can you all get jeff updated documentation before release? if so +1 (though I'm not a committer)
[15:12] <tdonohue> keithg: Yes, I'll touch base with Jeff to be sure he's still fine with March 1....last I talke to him, he said things were looking good on his end, as long as there are no more major problems found during testathon
[15:13] <keithg> thanks
[15:15] <tdonohue> Ok..the next-to-last topic (before a Jira Review): I've been mentioning a few times in our Dev meetings to start thinking about how we'd like to improve/change the release process for the next release (1.7) -- if there's anything we'd like to change we can do so. There are now 3 different proposals posted on the Wiki: http://wiki.dspace.org/index.php/Proposals#Release_Cycle.2FProcess_Proposals%3Cbr%20/%3E
[15:16] <tdonohue> I'd encourage everyone to read those and add your thoughts/ideas -- I'm working on scheduling a Special Topics meeting to discuss these in more detail. Right now it's between March 3 and March 10 -- if you have a preference let me know (it sounds like so far, March 10 may be better for most)
[15:18] * kshepherd jumps in, a little late
[15:18] <tdonohue> I'll send out an email on this as well, once I have a date scheduled -- but until then, I'd encourage thoughts/ideas (you don't have to be a committer to put in your thoughts/ideas on any of these proposals, or add your own proposal)
[15:18] <tdonohue> welcome, kshepherd :)
[15:19] <tdonohue> Any other topics / thoughts from anyone before we dig into a Jira Review?
[15:19] <mhwood> It would be good to hear from folks who are *not* in the code all the time (or ever) about their release concerns.
[15:19] <PeterDietz> I'm +1 on special topics, as I'm in the each release should have "something in it for me" that applies to a broad group, as opposed to just behind the curtains fixes
[15:19] <tdonohue> mhwood: I agree. I forgot to mention, this is only step #1 of this discussion
[15:20] <tdonohue> Valorie and I have been talking about splitting this release procedure discussion into ~3 parts:
[15:20] <tdonohue> #1 - Ask developers for input, thoughts, immediate "wins" from their standpoints
[15:20] <mhwood> Well, sometimes all you have is critical bugfixes, although there is probably enough pent-up feature work to give us a nice selection to schedule into each release for some time.
[15:21] <tdonohue> #2 - Talk to Repo Managers in community about their concerns or ideas around past release schedules, etc.
[15:21] <tdonohue> #3 - pull together these ideas into joint "proposals" or "plans" and start to figure out how we want to move forward
[15:22] <mhwood> Sounds good to me.
[15:22] <tdonohue> but, in all these steps, I don't want this to indefinitely delay any immediate work we (the devs) can do to start planning for 1.7 -- so, not all of this may have happened before we begin 1.7 work
[15:23] <tdonohue> mhwood: thanks! Anyone else have comments on this plan?
[15:23] <mhwood> Well, we should be able to converge on the developing plan.
[15:23] <kshepherd> yep sounds good
[15:23] <tdonohue> mhwood: exactly. we'd converge and move towards the developing plan, once it has been developed :)
[15:25] <tdonohue> ok...if there are no further comments right now, I'd like to suggest we dig into Jira and see what we can review!
[15:25] <kshepherd> ok. DS-487, DS-486, DS-485, DS-484 are all links to "howto" style doco.. should probably move the links to the wiki and inform Hilton.
[15:25] <tdonohue> kshepherd: yea, I noticed that. Do you want to take the lead on cleaning those up?
[15:25] <kshepherd> yep sure
[15:25] <tdonohue> thanks!
[15:26] <tdonohue> Ok, we last reviewed DS-466. Here's our running list: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-6w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[15:26] <tdonohue> so, we'll be starting with DS-467...let me pull that one up here, and we can start the voting
[15:27] <tdonohue> Consider making the JSPUI styles.css.jsp a static file: http://jira.dspace.org/jira/browse/DS-467
[15:27] <kshepherd> +1
[15:28] <mhwood> +1
[15:28] <kshepherd> mark D is a +1 too, if you read his comments ;)
[15:28] <tdonohue> +1 - seems like a quick win
[15:28] <tdonohue> (yea, i laughed at his comments...obviously mdiggory is watching a lot of olympics)
[15:28] <mhwood> Wait, is that 1.6.0 or 1.6.1?
[15:29] <kshepherd> 1.6.1 i guess.. bit late for 1.6.0 now?
[15:29] <mhwood> That was my thinking.
[15:29] <tdonohue> I'd say 1.6.1 as well.... only necessary fixes from here on out
[15:29] <tdonohue> (for the rest of this, we may want to add version #'s after our votes....e.g. +1 for 1.6.1, etc.)
[15:30] <tdonohue> Ok, that one passes for 1.6.1
[15:30] <kshepherd> though it is a small change... there's a chance people won't notice and will keep 'styles.css.jsp' in their modules/jspui/... dir, and wonder why their theme doesn't work anymore ;) so this change will need doco and maybe an announcement somewhere?
[15:30] <tdonohue> http://jira.dspace.org/jira/browse/DS-468 : CLONE - Foreign characters broken in group names.
[15:30] <mhwood> kshepherd: note that in JIRA?
[15:30] <tdonohue> kshepherd: I agree...i'll add a comment for docs to it in Jira
[15:30] <kshepherd> yeh
[15:31] <kshepherd> DS-468 looks good to me
[15:32] <kshepherd> but i haven't tested it
[15:32] <tdonohue> have you verified DS-468?
[15:33] <kshepherd> it just escapes groupName and the GET query string
[15:33] <tdonohue> ok, if it really is an issue, I'd vote +1 for 1.6.0 (small patch, necessary fix) -- but it'd be good to verify this problem first (to ensure it's not a misconfiguration causing it)
[15:34] <kshepherd> trye
[15:34] <mhwood> +1 awaiting independent confirmation
[15:34] <tdonohue> anyone want to volunteer to confirm it?
[15:34] <kshepherd> just trying now
[15:35] <tdonohue> ok, can I assign to you then, kshepherd. If confirmed, I'd say this seems like something we can commit immediately
[15:35] <mhwood> Still trying to figure out how to type those characters here.
[15:35] <kshepherd> yep no prob
[15:35] <tdonohue> (mhwood - I use copy & paste from Word for those types of chars)
[15:36] <kshepherd> utf8 is sometthing we have to deal with a lot... the macrons we use for long vowels arent in ISO charsets :P
[15:36] <tdonohue> ok, assign DS-468 to kshepherd for verification
[15:36] <tdonohue> http://jira.dspace.org/jira/browse/DS-469 : DCDate.displayDate(false,*) displays only year
[15:36] <mhwood> +1 1.6.1 :-)
[15:36] <tdonohue> +1 - 1.6.1 as well....good catch on this
[15:37] <kshepherd> +1 1.6.1
[15:37] <tdonohue> http://jira.dspace.org/jira/browse/DS-470 : Batch import times increase drastically as repository size increases; patch to mitigate the problem
[15:37] <tdonohue> Oh, this is the large problem that grahamtriggs has been helping with
[15:38] <tdonohue> +1 for 1.6.1 or 1.7 :)
[15:38] <kshepherd> (re ds-468 i just got "java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: "u0"" when i tried to great a group name called 'māori')
[15:38] <kshepherd> ah, uh oh.. this issue ;)
[15:38] <tdonohue> kshepherd: ok, sounds like you verified it then...if the fix works for DS-468, I'd say go ahead and commit it
[15:39] <mhwood> DS-470, +1, post-1.6.0.
[15:39] <grahamtriggs> DS-470: +1 for addressing the issues post-1.6.0. -1 for applying the patch as it stands
[15:39] <tdonohue> yea, I think DS-470 will require a bit more work/discussion..i'd agree with grahamtriggs
[15:40] <tdonohue> ok, we'll leave it at that for now
[15:40] <kshepherd> DS-470 +1 to the general idea, but graham had some reasonable objections to viewing "speeding up batch jobs" as a priority over "reducing system load"
[15:40] <mhwood> Good point.
[15:40] <tdonohue> http://jira.dspace.org/jira/browse/DS-471 : Accessing site-level 'mets.xml' in XMLUI doesn't work properly for handle prefixes with periods (e.g. 2010.1)
[15:41] <tdonohue> Note: DS-471 came across dspace-devel - The patch is small, but I haven't had a chance to verfy it
[15:41] <kshepherd> i tested this patch, it works
[15:41] <grahamtriggs> kshepherd: that's more an issue about calling it 'scalability' when it's only improving performance in one specific case. the real problem is in the (unnecessary) breaking of the encapsulation
[15:41] <tdonohue> should we let DS-471 into 1.6.0? Or wait for 1.6.1 -- thoughts?
[15:41] <kshepherd> that too..
[15:42] <tdonohue> (I'll admit, I don't know how many people encounter DS-471 -- so, I don't know if it's a minor or major annoyance)
[15:43] <tdonohue> Ok, I'll stand out on a limb and vote +1 1.6.0 for DS-471
[15:44] <kshepherd> yeah +1, since handle prefixes are rightly treated as strings everywhere else, pretty much
[15:45] <mhwood> +0, I'd need more context than the patch gives to feel better about it
[15:46] <kshepherd> but i'm thinking most of our 1.6.0 pushes should just be the bugs found during testathon?
[15:47] <tdonohue> kshepherd: yes..essentially, I'd like to limit 1.6.0 pushes to just necessary bug fixes... (whether they are found specifically in testathon doesn't matter to much to me)
[15:48] <tdonohue> so, the question is, is this a *necessary* bug fix...for now, it sounds like we are wavering, so we probably should wait for 1.6.1 afterall
[15:48] <kshepherd> i think waiting would be fine
[15:48] <tdonohue> DS-471 summary: +2, with questions...wait for 1.6.1 release
[15:48] <kshepherd> the tiny minority who use dots in handle prefixes can grab the patch from JIRA ;)
[15:49] <tdonohue> http://jira.dspace.org/jira/browse/DS-473 : cocoon.log permissions seem incorrect
[15:49] <tdonohue> kshepherd: true :)
[15:49] <kshepherd> ds-473 looks like a 'linux system administration' issue to me :P
[15:50] <tdonohue> yea, I was just going to say that
[15:50] <tdonohue> -1 : mark not a bug -- followup with help/suggestions?
[15:50] <mhwood> I agree. Tomcat expects to own the stuff it touches and it's very difficult to get around that. Maybe the submitter could handle this with Posix ACLs?
[15:51] <tdonohue> anyone want to follow up with him, give a few suggestions, and close this?
[15:51] <kshepherd> yes, ACLs offer much more than the simple user/group modes
[15:51] <mhwood> I can follow up.
[15:51] <kshepherd> however, just changing tomcat's umask in /etc/bashrc or whatever will do it
[15:51] <tdonohue> DS-473: Assign to mhwood to followup. Can be closed after followup
[15:51] <kshepherd> (cause new files to be 664 instead of 644)
[15:52] <tdonohue> http://jira.dspace.org/jira/browse/DS-474 : handle.canonical.prefix undocumented
[15:52] <kshepherd> ah yes, we discovered this in #dspace a few weeks ago, iirc..
[15:52] <tdonohue> is it just missing from dspace.cfg, and docs then?
[15:52] <kshepherd> i believe that's the case
[15:53] <kshepherd> http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg04978.html
[15:53] <kshepherd> it's been that way since at least 2008, too ;)
[15:54] <tdonohue> Well, if someone wants to volunteer to add it (minimally to dspace.cfg), I'd vote +1 1.6.0
[15:54] <kshepherd> ok assign to me if you like
[15:55] <kshepherd> i have a conference call in 5 minutes
[15:55] <tdonohue> ok, i'll assign to kshepherd. Thought we need three +1's to officially vote it into 1.6.0 (per our voting procedures)
[15:55] <kshepherd> oh, whoops
[15:55] <kshepherd> +1 1.6.0
[15:55] <mhwood> +1
[15:55] <kshepherd> :)
[15:55] <tdonohue> ok, thanks :)
[15:55] <tdonohue> http://jira.dspace.org/jira/browse/DS-476 : READ action
[15:56] <tdonohue> (trying to squeeze in one or two more before kshepherd has to leave)
[15:56] <tdonohue> Oh, this one: DS-476 needs more discussion. This is based on how things have always been implemented in DSpace...plus no patch
[15:57] <mhwood> Yes, more discussion. We keep seeing things like this, all over the place. There's a need to step back and look at them in context.
[15:58] <kshepherd> yeah
[15:58] <tdonohue> DS-476: Needs more discussion.
[15:58] <kshepherd> +0, needs more discussion
[15:58] <tdonohue> Ok, i'll stop there then.
[15:59] <tdonohue> I think most of the current issues are minor, but I'd appreciate thoughts/comments on them if any of you get a chance
[15:59] <kshepherd> i'll be semi-here, just on my regular lconz conference call so might go afk sometimes
[16:00] <tdonohue> ok. I think we'll still have to stop anyways, as we technically need three +1 votes...and I think only 3 of us have really been active :)
[16:01] <tdonohue> But, I'd appreciate it if everyone could take time in the next week to review any new or incoming issues...
[16:01] <kshepherd> oops
[16:01] <kshepherd> its at 11am, not 10am
[16:01] * kshepherd just joined the wrong conf call ;)
[16:01] <mhwood> Ouch
[16:01] <tdonohue> oh..so, you are still here? Do you two want to continue?
[16:02] <mhwood> We can
[16:02] <kshepherd> sure
[16:02] <tdonohue> http://jira.dspace.org/jira/browse/DS-478 : Monitoring class run as a scheduled (cron) task to 'ping' the installation URL and report if no valid response is received.
[16:02] <tdonohue> (ok...let's push through then...as long as you are both available)
[16:03] <kshepherd> DS-478: hm. this looks like a strange way to achieve monitoring
[16:03] <tdonohue> +0 : there's other monitoring software out there that does this better. Not sure it should be part of DSpace
[16:03] <mhwood> Yes, 478 seems as though it might be a little too specific to the way a particular site does monitoring.
[16:03] <kshepherd> monitoring software should *never* be part of what it's trying to monitor ;)
[16:04] <kshepherd> and hopefully not even on the same physical machine!
[16:04] <tdonohue> ok...I'll assign this to myself and add a comment similar to this
[16:04] <tdonohue> http://jira.dspace.org/jira/browse/DS-479 : CC Web Service API: XMLUI almost completed ... willl need JSPUI change too
[16:05] <tdonohue> +1 for the idea...but, no patch yet. so, this obviously needs to wait
[16:05] <mhwood> Not yet, no patch.
[16:05] <kshepherd> yeh +1 also
[16:05] <kshepherd> would be good to see what the patch looks like so far, even if it's not finished
[16:05] <kshepherd> we could comment to that effect?
[16:05] <tdonohue> sure, if you want to comment kshepherd, feel free. I know MIT is developing this, and I'm not sure how far along it is yet
[16:06] <kshepherd> cool
[16:06] <tdonohue> http://jira.dspace.org/jira/browse/DS-480 : Exception is thrown when removing the last file after the item is rejected during review.
[16:07] <tdonohue> DS-480: +0 huh? i'm confused. needs verification, clearer description
[16:07] <kshepherd> description is not too clear
[16:07] <kshepherd> the patch might exmplain it better ;)
[16:08] <tdonohue> Oh! it's just adding an "if (bundles.length >0)"...that's much clearer
[16:08] <kshepherd> it checks to see if there are any bitstreams left in the bundle before applying setPrimaryBitstream to bundle[0]
[16:08] <tdonohue> ok, well, that makes much more sense now :)
[16:08] <kshepherd> hehe, funny how code can sometimes speak clearer than english ;)
[16:08] <mhwood> Yes, would be nice if the patch were explained.
[16:08] <PeterDietz> sorry to have slipped away, Olympic hockey drew me in... for DS-476 does more discussion mean more info should be on the ticket? I was online and responding to some of the questions brought up when he created the issue, I can add some more context/description as a comment.
[16:09] <mhwood> 480: OK, that makes sense.
[16:09] <tdonohue> DS-480: +1 1.6.0 (very minor fix, and seems like an "if" stmt that should've already been there)
[16:09] <kshepherd> +1 on 480 1.6.0
[16:09] <mhwood> +1 480 1.6.0
[16:10] <kshepherd> PeterDietz: adding comments to the jira issue is always helpful
[16:10] <tdonohue> PeterDietz: essentially, "needs more discussion" means we need to figure out the full scope of the issue, and some potential fixes...
[16:10] <tdonohue> PeterDietz: right now there are some problems presented, but we need to determine ways to resolve them logically before much can be done about it
[16:10] <mhwood> 476: what I worry about is that there are scads of these complaints, and fixing them all piecemeal may be a poor approach.
[16:11] <kshepherd> yeah, the whole authn system needs discussion
[16:11] <tdonohue> Volunteer to commit DS-480 immediately?
[16:11] <mhwood> Will do 480
[16:11] <kshepherd> tdonohue: sure
[16:11] <tdonohue> DS-480: +3 for 1.6.0 assign to mhwood to commit
[16:11] <kshepherd> or mhwood can ;)
[16:11] <kshepherd> he said it first!
[16:11] <tdonohue> mhwood beat you to it :)
[16:12] <kshepherd> "you touched it last!"
[16:12] <mhwood> OK, I have DS-480
[16:12] <tdonohue> ack, i accidentally closed my browser...lost my place...just a sec
[16:13] <tdonohue> http://jira.dspace.org/jira/browse/DS-481 Unable to remove the last file after the item is rejected during review.
[16:13] <kshepherd> that looks odd
[16:13] <kshepherd> needs verification, and no patch
[16:13] <kshepherd> i don't think i've ever encountered this
[16:14] <mhwood> No patch, needs investigation
[16:14] <tdonohue> yea, it needs verification...anyone to volunteer?
[16:14] <tdonohue> also, it doesn't say if this is XMLUI or JSPUI...
[16:14] <tdonohue> needs followup as well
[16:14] <kshepherd> or even which dspace version ;)
[16:15] <tdonohue> DS-481: Tim will followup. We need more details, etc.
[16:16] <tdonohue> skipping DS-482 - it's Serbian Translation...can be released later (translations are separate)
[16:16] <tdonohue> http://jira.dspace.org/jira/browse/DS-483 : statistics.item.authorization.admin ignored by xmlui
[16:16] <tdonohue> (also claudia is already working on DS-482...fyi)
[16:17] <kshepherd> so, this seems to be either a typo in the xmlui stats when it does the getProperty for statistics.item.authorization.admin
[16:17] <kshepherd> OR.. ben has assumed the opposite of what i assumed when we looked at 'statistics.item.authorization.admin'
[16:17] <kshepherd> my understanding was that this meant "admin-only access for stats"
[16:17] <tdonohue> yea, that'd be my assumption as well.... "true" means admin-only
[16:17] <kshepherd> which is why JSPUI blocks non-admins from viewing if statistics.item.authorization.admin=true
[16:18] <kshepherd> but this is still quite an ambiguous parameter
[16:18] <kshepherd> statistics.public = false would be better, imho
[16:18] <tdonohue> yea, the parameter is badly named in general...it has nothing to do with "item" for one
[16:18] <mhwood> Community discussion on what this ought to mean, or what it is that people want to configure?
[16:19] <kshepherd> mhwood: what people feel is more intuitive when they're editing dspace.cfg for the first time, i guess..
[16:19] <tdonohue> I think we know what it currently means. It enables/disables whether stats are public vs. admin-only.
[16:19] <kshepherd> here's the XMLUi code that ignores it
[16:19] <kshepherd> http://scm.dspace.org/svn/repo/dspace/trunk/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/statistics/StatisticsAuthorizedMatcher.java
[16:20] <tdonohue> what peopole want to configure is another question (cause it could be a lot of things), and it's post 1.6.0 :)
[16:20] <kshepherd> ok, sure, lets not worry about the wording
[16:20] <tdonohue> kshepherd: Can you work to sync that code up with JSPUI code, since you know this well?
[16:21] <kshepherd> it's kidna confusing, actually
[16:21] <kshepherd> quite different to my jspui implementation
[16:21] <tdonohue> oh, ok.
[16:21] <kshepherd> i know the backend stats api code, and the jspui, but not the xmlui stuff :/
[16:21] <kshepherd> can i paste big here? ;)
[16:22] <tdonohue> I'll send an email to ben bosman and mdiggory about this then...see if one of them will fix it to work the same as JSPUI for now
[16:22] <kshepherd> ok
[16:22] <tdonohue> DS-483 : Tim will contact @mire for a fix
[16:23] <tdonohue> Ok...skipping DS-484 through 487 -- they will be assigned to kshepherd to ask to post on wiki
[16:24] <tdonohue> http://jira.dspace.org/jira/browse/DS-488 : Admin aspect URI's fail after logging in as adminstrator
[16:24] <tdonohue> oh, whoops. DS-488 seems to be invalid. mdiggory already responded to it
[16:24] <tdonohue> http://jira.dspace.org/jira/browse/DS-489 : OAI-ORE, References to bitstreams in harvested records incorrect
[16:25] <keithg> to comment on DS-489, the links to external bitstreams are incorrect when jspui systems are harvested, but not when xmlui systems are harvested
[16:25] <mhwood> Looks resolved to me.
[16:26] <tdonohue> is it resolve though? this seems odd that we'd give different links based on which system is being used? or am I misunderstanding?
[16:27] <tdonohue> does JSPUI actually have different bitstream links? oh..maybe it does (testing now)
[16:27] <tdonohue> oh..it does..my bad :)
[16:27] <mhwood> IIRC it has to work that way because the two UIs have different ways of building URLs.
[16:28] <mhwood> I do see an open question, though: how to configure it for the right style.
[16:28] <tdonohue> yea, you are right mhwood
[16:29] <tdonohue> and I don't know the answer to that question? do any of you?
[16:29] <mhwood> No
[16:29] <kshepherd> nope
[16:29] <mhwood> Needs more study so we can document proper use
[16:29] <tdonohue> ok. DS-489: will mark needs more investigation. needs a volunteer as well
[16:30] <tdonohue> http://jira.dspace.org/jira/browse/DS-490 : DSpace User Manual suggestions, Chapter 1
[16:30] <tdonohue> wow. those are some old comments ("Dspace 1.2") -- good catch keithg
[16:30] <keithg> nitpicky but I can't find real bugs anymore - you squashed the good ones
[16:31] <tdonohue> haha...well, that's good to hear, actually!
[16:31] <kshepherd> it's ok
[16:31] <kshepherd> i've hidden some real nasty ones
[16:31] <kshepherd> ;)
[16:31] <kshepherd> (KIDDING)
[16:31] <keithg> :)
[16:31] <tdonohue> ok, I'll ask Jeff about DS-490...see if we can at least just get the broken links fixed
[16:31] * kshepherd needs to quickly grab a coffee before the [correct] conf call starts
[16:31] <kshepherd> brb
[16:32] <tdonohue> Ok...only four left? you still good mhwood?
[16:32] <mhwood> Still here.
[16:32] <tdonohue> http://jira.dspace.org/jira/browse/DS-491 : Ability to map collections to multiple communities
[16:33] <tdonohue> This is a nice feature request, but obviously post 1.6.0, and we need discussion/implementation
[16:33] <mhwood> Looks like an implicit feature request. Needs develpment
[16:33] <tdonohue> http://jira.dspace.org/jira/browse/DS-492 : jspui Browse by author "Jump to" menu
[16:34] <mhwood> Patch withdrawn by author. But it once again exposes something that should be addressed: skew between JSPUI and XMLUI. We need to work out what can be harmonized and document what won't be.
[16:35] <tdonohue> Oh, so this isn't really a bug...just a UI oddity, in that there's a "Jump to menu" even if everything is being displayed on one page
[16:35] <tdonohue> DS-492: Needs more discussion. UI harmonization perhaps, but we need a patch, etc.
[16:35] <tdonohue> http://jira.dspace.org/jira/browse/DS-493 : Url in browser is incorrect after login
[16:36] <mhwood> Needs fixing, when we understand why it happens.
[16:37] <tdonohue> I'd agree. DS-493 needs more investigation. Not ready for 1.6.0 as we don't know why or how to fix
[16:37] <mhwood> At first glance it sounds like a browser quirk.
[16:37] <tdonohue> yea, in any case, seems relatively minor, and may not need an immediate fix
[16:37] <tdonohue> http://jira.dspace.org/jira/browse/DS-494 : DatabaseManager.process() unnecessarily limits range of DECIMAL or NUMERIC
[16:38] <tdonohue> (last, but not least!)
[16:38] <tdonohue> mhwood: so, this is not meant for 1.6.0, right. Just something to resolve for 1.6.1? Or is it causing big issues?
[16:38] <mhwood> I'm nervous about changing something so deep in the core of what DSpace does. No, I would recommend against putting it in 1.6.0
[16:39] <tdonohue> ok. This sounds like a good fix to me, but I'd also vote post-1.6.0. Needs more eyes on it, more testing from both Oracle & PostgreSQL folks
[16:39] <mhwood> I don't know of another case where this causes problems, but it looks incorrect as is.
[16:40] <mhwood> Yes, more eyes please.
[16:40] <tdonohue> Ok. sounds good.
[16:41] <tdonohue> That's it! we are caught up!
[16:41] <mhwood> Yay!
[16:41] <kshepherd> back
[16:41] <tdonohue> I'll go back and paste our comments into each of these issues in Jira
[16:41] <tdonohue> kshepherd: you missed the excitement of the final 4 :)
[16:42] <tdonohue> Ok. Thanks a ton for sticking around to catch up on Jira, kshepherd and mhwood. I really appreciate it.
[16:42] <mhwood> You are welcome.
[16:43] <tdonohue> If any of you notice anything new come through that needs to get into 1.6.0 and there are any questions, email Stuart & I and we can help out. As I mentioned, it's likely neither of us will be on IRC much, if at all, next week
[16:43] <mhwood> Will do.
[16:43] <tdonohue> That's it. Thanks again. Meeting adjourned!
[16:43] <kshepherd> cheers guys
[16:43] <mhwood> 'bye all.
[16:43] <kshepherd> not quite a quorum, but we did ok
[16:43] <tdonohue> bye!
[16:44] <tdonohue> yea...good enough...we only need 3 for the big votes...so, in this case, 3 is a "good enough" quorum :)
[17:01] * kshepherd spams dspace-devel with the same comment four times ;)
[17:04] <keithg> night everyone
[17:04] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithg)
[17:04] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[18:03] * stuartlewis (~stuartlew@n219076092198.netvigator.com) has joined #duraspace
[18:18] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:31] * stuartlewis (~stuartlew@n219076092198.netvigator.com) Quit (Quit: stuartlewis)
[21:16] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[22:17] * cccharle` (~user@131.104.62.47) has joined #duraspace
[22:26] * cccharles (~user@131.104.62.47) Quit (Ping timeout: 265 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.