Timestamps are in GMT/BST.
[5:52] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[6:34] -card.freenode.net- *** Looking up your hostname...
[6:34] -card.freenode.net- *** Checking Ident
[6:34] -card.freenode.net- *** Found your hostname
[6:34] -card.freenode.net- *** No Ident response
[6:34] [frigg VERSION]
[6:34] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:34] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:34] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[7:09] * aways (~bmorel@2001:660:5301:11:219:b9ff:fe1a:38e7) has joined #duraspace
[7:09] <aways> hi all
[7:28] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[12:21] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:37] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 260 seconds)
[12:51] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[13:06] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[13:27] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:55] * aways (~bmorel@2001:660:5301:11:219:b9ff:fe1a:38e7) has left #duraspace
[14:09] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[14:33] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[17:59] -card.freenode.net- *** Looking up your hostname...
[17:59] -card.freenode.net- *** Checking Ident
[17:59] -card.freenode.net- *** Found your hostname
[18:00] -card.freenode.net- *** No Ident response
[18:00] [frigg VERSION]
[18:00] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[18:00] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[18:00] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[19:53] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:57] <tdonohue> Hey all -- DSpace Devel Mtg starting here in a few minutes. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-09-08
[19:58] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) has joined #duraspace
[20:00] * richardrodgers (~richardro@dhcp-18-111-12-48.dyn.mit.edu) has joined #duraspace
[20:00] <tdonohue> Well it's the top of the hour -- may as well get started with our Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-09-08
[20:01] <tdonohue> First off, JIRA review (as usual) : http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-18w&assigneeSelect=&sorter/field=created&sorter/order=ASC
[20:01] <tdonohue> We'll be starting with DS-612
[20:01] <tdonohue> DS-612 : Unfinished submissions see cc-rdf file instead of their uploaded PDF in the uploads step. http://jira.dspace.org/jira/browse/DS-612
[20:03] <richardrodgers> I'd like to see if this is still a problem with the new CC license stuff - assign to me?
[20:03] <tdonohue> ok -- will do. it definitely needs verification with the new CC license code :)
[20:04] <tdonohue> DS-612 -- assign to richardrodgers for verification & testing with new CC license code (from MIT)
[20:04] <mhwood> Comment says it's side effect of a fixed bug.
[20:04] <tdonohue> DS-613 : Error Handling in the XMLUI interface after section expired http://jira.dspace.org/jira/browse/DS-613
[20:04] <grahamtriggs> sounds like the rdf should be internal - which is not the same as saying it doesn't get exposed ever by any part of the system (otherwise there wouldn't be any point in storing it)
[20:05] <tdonohue> mhwood -- yea, I think the fix for the other bug caused this DS-612 problem -- in either way, MIT is reworking the CC License stuff, so once that code is in, it *may* fix DS-612
[20:07] <tdonohue> Thoughts on DS-613 ? Seems like it might be logical to try and catch this "invalid continuation" error and at least display a nicer "Your Session has Expired" page ?
[20:07] <mhwood> DS-613: well, it shouldn't do *that*. If the session is expired then doesn't the user need to login again? And if so, what is the state of the submission?
[20:07] <mhwood> *That* was meant to be "throw an invalid-continuation page".
[20:08] <tdonohue> yea, I agree mhwood -- it needs to at least display some sort of nice message (even if that message is just "please login again"
[20:08] <grahamtriggs> not clear how continuation and login are related (may not necessarily have the same lifecycle).... should have a nicer error if possible
[20:08] <mhwood> The poor user probably has no idea what an invalid continuation is.
[20:08] <richardrodgers> +1 but needs a volunteer
[20:09] <tdonohue> grahamtriggs -- 'invalid continuation' is basically Cocoon reporting that it has lost its session info
[20:09] <tdonohue> +1 -- any volunteers?
[20:10] <grahamtriggs> yes, but is that the same as a http (/ dspace) session? eg. frameworks like Seam have multiple lifecycles that aren't related to the HTTP session
[20:10] <mhwood> So how does the user get a new valid session?
[20:11] <mhwood> Or whatever it is called.
[20:12] <tdonohue> I think basically they need to relogin. Something in cocoon has "timed out" -- so it's either increase the cocoon timeout (as cocoon imbeds 'continuation IDs' into each HTML page and uses those to keep its 'context'), or catch this exception and display a nicer page
[20:12] <tdonohue> I can dig into this one a bit -- if I cannot figure it out, we'll revisit. Assign DS-613 to tdonohue for analysis.
[20:12] <grahamtriggs> and similarly, could we be potentially use a continuation for an anonymous session (ie. refining search queries)
[20:12] <mhwood> Yes, if we can't tidy things automatically then we must tell the user what he needs to do in terms he understands.
[20:13] <mdiggory> continuations actually are maintained separate from sessions in Cocoon. I'm not 100% sure how thy get expired with the session.
[20:13] <tdonohue> grahamtriggs -- right. eventually. Currently though we are really only using continuations in places where a user is logged in -- so, right now, when the continuation times out, it can be refreshed with a login
[20:14] <grahamtriggs> so we should be careful in our handling not to tie the message to 'you must log in again', as that may not always be true
[20:15] <tdonohue> possibly. I'm not sure if that's even the best resolution (to display a nicer error page) -- it's possible there's a way to just avoid this problem by trying to extend the timeout. It basically needs further analysis before we can make a decision
[20:15] <mhwood> The association with session may be just what the reporter thinks is happening. Still, how does the user get a fresh continuation or get back into the process he was following?
[20:17] <tdonohue> mhwood -- continuations are setup during processes like Editing or a new submission. So, essentialy if your continuation is gone, you have to relogin in and then go back to edit that item or continue your submission.
[20:17] <mdiggory> not particularly thrilled with continuations in cocoon actually. (1) they make debugging difficult. (2) they are javascript (3) make sending out details about where to complete an administrative task difficult (3) Force al XMLUI Admin functions into one aspect/flowscript (4) arn't very restful
[20:17] <tdonohue> mhwood -- but as grahamtriggs pointed out, it's possible to use continuations in other areas as well
[20:18] <mhwood> Unfriendly -- I HATE sites that drag you through a long complex process only to find that you've been timed out in the interval.
[20:18] <tdonohue> mdiggory -- yea, I'd not be against discontinuing them -- but, that's a much larger project to rip out Cocoon continuations altogether :(
[20:19] <tdonohue> any other thoughts on this? Should we open up a 'placeholder' issue to investigate removing usage of continuations altogether?
[20:20] <mdiggory> possible example of handling the error differently....
[20:20] <mdiggory> http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html
[20:21] <tdonohue> thanks for the link -- I thought there was a better way to catch the error, minimally
[20:21] <tdonohue> Ok, for now, assign DS-613 to tdonohue for investigation.
[20:21] <mdiggory> more specifically... the handle errors section of the sitemap code
[20:21] <mdiggory> <map:handle-errors>
[20:21] <tdonohue> DS-614 : [XMLUI] Multi-page forms error http://jira.dspace.org/jira/browse/DS-614
[20:22] <grahamtriggs> won't resolve - if you've got more than 10 pages in your describe forms, you are going to have some seriously irritated users
[20:22] <tdonohue> this seems unlikely that many people would want a 10 pg submission process
[20:23] <richardrodgers> Emerged in testing I hope - how could you subject users to 10 describe pages? :(
[20:23] <mhwood> Could we do something less surprising than wrapping the step around to 0?
[20:23] <tdonohue> yea, maybe we just need to document that you cannot have more than 10 pages in the describe step :)
[20:23] <mdiggory> seems type based submission should alleaviate some complexity in creating/using multiple page forms?
[20:24] <grahamtriggs> mhwood: yes, we can detect it and put up a message: "STOP YOU FOOL"
[20:24] <mhwood> *sigh* s/0/1/
[20:25] <mdiggory> what Pere points out is an instability in the code though
[20:25] <richardrodgers> I think we did document that more than 6 describe pages mucks up the breadcrumbs....
[20:25] <tdonohue> Ok, anyone want to tackle this then? volunteer?
[20:25] <mhwood> Exactly. It's abusing Double to encode two integers.
[20:26] <mhwood> Let me have it.
[20:26] <mdiggory> thats the spirit
[20:26] <tdonohue> ok -- assign DS-614 to mhwood . Thanks Mark!
[20:26] <tdonohue> DS-615 : Ability to perform maintenance on SOLR with solr.optimize http://jira.dspace.org/jira/browse/DS-615
[20:27] <tdonohue> Peter has already claimed this -- so, I'm assuming he's working on it for 1.7...any quick comments to pass along to Peter?
[20:27] <tdonohue> I'd be +1 this -- we need to be maintaining Solr indexes better
[20:27] <mhwood> +1
[20:28] <mdiggory> +!
[20:28] <mdiggory> light enough
[20:28] <tdonohue> ok -- we'll just move on to one last one
[20:28] <tdonohue> DS-616: Make it possible to guarantee config file values are filled thru the ConfigurationManager API http://jira.dspace.org/jira/browse/DS-616
[20:30] <tdonohue> ?? I thought most of our code tends to check for configs and report if they are missing (rather than throwing NullPointers?). Beyond that, I'm not sure what else is implied?
[20:30] <mhwood> Maybe this should be part of moving toward ConfigurationService?
[20:31] <grahamtriggs> I don't like the proposed solution - if anything it should be a separately named method, not a boolean parameter (which in itself would be confusing with the operation of getBooleanProperty)
[20:32] <tdonohue> Yea, I guess the ConfigurationService could help this perhaps -- though in general we should be checking for existance of configs when they are needed
[20:32] <grahamtriggs> but if you are going after the places in the code to force them to call the configuration manager in a certain way, then you can go after them to simply check the return values properly and log meaningful (instead of generic) messages
[20:33] <mdiggory> ConfigurationService accepts default values for parameters when looking them up.
[20:33] <richardrodgers> also wouldn't this require all callers of ConfigManager to rewrite code (a big deal)?
[20:33] <mdiggory> ConfigurationService should replace COnfigurationManager wherever possible
[20:34] <mdiggory> but I'm not so keen on the ticket, its upto the calling code to deal with the failure to retrieve a value appropriately
[20:34] <mdiggory> and to supply sane defaults in the code, not the configuration file
[20:35] <grahamtriggs> mdiggory: it's not just default values - sometimes there isn't a sensible default, you must have something configured. But the answer is to make the calling code work correctly, not fudge it inside the API
[20:35] <tdonohue> I agree -- I'd vote -1 on this issue, but I think we find places where the code is not catching the potential NullPointer, and fix it there
[20:35] <richardrodgers> so annotate ticket 'for further study'
[20:35] <mdiggory> in fact... dependening on implementation, the source of the configuration value is abstracted away from the file itself
[20:36] <mdiggory> could be database... could be some other source...
[20:36] <mdiggory> agree... further study
[20:36] <tdonohue> yea, we probably should just mark this "for further study" and keep it in mind as we move towards ConfigurationService
[20:36] <mhwood> Yes, needs more thought.
[20:36] <tdonohue> ok, DS-616 -- needs more study -- keep in mind for ConfigurationService
[20:36] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[20:37] <PeterDietz> hi all, sorry for being late
[20:37] <tdonohue> we'll stop there for today ... and move on to 1.7 updates (just in time PeterDietz!)
[20:37] <PeterDietz> ok, I'll not jump into the unpopular here are all the remaining tasks (unclaimed, but look for at them for yourself)
[20:38] <tdonohue> Any updates for 1.7 -- PeterDietz or anyone else? Note -- we are only 6 weeks away from "Freeze"
[20:38] <richardrodgers> Curation branch is coming along - by tomorrow there will be UI code (XMLUI only the the moment)
[20:39] <PeterDietz> unofficially, a peer and I at work have been working on a php-ui for the dspace datamodel
[20:39] <PeterDietz> ...however, that is not something for the release
[20:39] <tdonohue> PeterDietz -- built on what? REST? direct to Java API?
[20:40] <PeterDietz> I want to work more closely with existing dspace functionality, so hopefully something like dspace-api. However its just an introspection of the database, so its a read only direct database access. So you can list communities, collections, items, bitstreams, bundles
[20:41] <PeterDietz> I don't want to derail real dspace work with this, but its sitting in github for those who are curious, http://github.com/jamespaulmuir/cotinga
[20:42] <grahamtriggs> a php-ui isn't really something to be released as part of DSpace though? Just necessary supporting parts (ie. REST services)
[20:42] <tdonohue> oh, i see -- I was just curious as there's no "easy way" to put another, non-Java-based UI on DSpace yet (but, this is what I was hoping REST API could eventually help with)
[20:43] <PeterDietz> absolutely, it would be *best* if there was an easy cross platform way to talk to dspace. And our work so far is cross platform, but it completely bypasses everything that is good about dspace, just to access some data.
[20:43] <tdonohue> grahamtriggs -- no, not something to be released as part of DSpace (at least not unless it gathered wide acceptance as a "better UI solution" from committers/developers/users)
[20:44] <mdiggory> sigh... knew I was going to eventually need to learn php....
[20:44] <tdonohue> ok -- we're a bit off topic here, though it is interesting :) other 1.7 updates/thoughts?
[20:45] <grahamtriggs> tdonohue: I think I can hear that can of worms creaking...
[20:45] <PeterDietz> yeah, so Oct 22 is feature freeze. Thats next month plus a few weeks, so all the real projects should progress and be committed somewhere by then
[20:45] * tdonohue looks around? what can of worms? :)
[20:45] <PeterDietz> the brain?
[20:47] <PeterDietz> ok, and after oct 22, there is a quick ramp up of scheduling deadlines, especially for quality control which means that you'll be best getting work completed sooner than later.
[20:47] <PeterDietz> most notably testathon being three weeks after feature freeze
[20:48] <tdonohue> Yep -- and actually, to clarify, Oct 22 is Feature Freeze -- no new features after then -- bug fixes are fine, but no other code changes are allowable (unless formally approved by PeterDietz)
[20:48] <tdonohue> Ok -- is that it for 1.7 stuff? any other comments/questions?
[20:49] <tdonohue> I'll take that silence as a "no" :)
[20:50] <mdiggory> continuing work on async release in trunk... branch created before the laborday holiday
[20:50] <richardrodgers> I'll announce a 'contest' soon around curation - big prizes!
[20:50] <mdiggory> http://scm.dspace.org/svn/repo/sandbox/dspace-async-prototype/
[20:50] <tdonohue> mdiggory -- yea, is it going well, or just beginning still?
[20:51] <mdiggory> not much news yet, want to formalize the process and suggest others are welcome to join in if interested
[20:51] <tdonohue> richardrodgers -- sounds great :) prizes always welcome
[20:51] <tdonohue> mdiggory -- sounds good -- I'm keeping an eye on it, but haven't had a chance to pull it down yet
[20:52] <tdonohue> Oh, I forgot to add this to the agenda -- I'm going to be out next Weds (DuraSpace team meeting). Any volunteers to lead next weeks meeting?
[20:52] <richardrodgers> I'd like to encourage committers & other developers to add their own tasks - we can distribute the best in 1.7
[20:52] <mdiggory> initial ideas involve breaking apart dspace-parent into separate project and discontinuing use of dependencyManagement for "trunk" modules like dspace-api etc
[20:53] <PeterDietz> tdonohue, would you be interested in coming up with an agenda for next weeks meeting?
[20:54] <tdonohue> PeterDietz -- if you pay attention recently, we've had essentially the same agenda for the last 3-4 meetings :) (1) JIRA review, (2) 1.7 Updates, (3) if anything else comes up during the week, discuss it
[20:54] <tdonohue> so, there's an agenda for you :)
[20:54] * mhwood wonders how to build a tool that will return a list of included components and versions, so we can still answer the question "what DSpace are you running?"
[20:56] <mdiggory> ls -a -l xmlui/WEB-INF/lib ?
[20:57] <tdonohue> needs to be easier than that :) not everyone has Linux or is a developer. would be nice to have a modules list in Admin UI
[20:58] <tdonohue> but, I understand that concern -- it's something we need to think about -- we need to be able to say "I'm running DSpace 1.8, with the following optional modules: rest-api v. 1.8.2, etc etc"
[20:58] <PeterDietz> I can work with that tdonohue, so I can lead discussion next week.
[20:58] <tdonohue> thanks PeterDietz! I'll be available on email all week -- just not sure I'll be able to pull away from the meetings to attend the IRC discussion
[21:00] <tdonohue> Last topic teaser: I think we need to discuss what our committer policies should be around the Unit Tests. We likely need to enforce using these Unit Tests & updating them as part of our committer guidelines: https://wiki.duraspace.org/display/DSPACE/Guidelines+for+Committing
[21:00] <tdonohue> I'm not looking for a decision/vote today -- I just wanted to bring this up as something we need to all be thinking about
[21:00] <kshepherd> hi all, sorry i missed the meeting :/
[21:00] <mhwood> I like the suggestion -- existing tests must pass, strongly encouraged to provide new tests for new code.
[21:01] <tdonohue> Yea, my recommended language (as mhwood points out) is here: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-09-08
[21:02] <tdonohue> obviously, we cannot require unit tests for everything, as most of our code (besides org.dspace.content.*) still doesn't have any unit tests
[21:03] <PeterDietz> ok, so this meeting is adjourned.
[21:03] <grahamtriggs> tdonohue: JIRA migration? (:strokes the duraspace jira:)
[21:03] <mhwood> After a period of getting used to the framework and the style of development, policies can be stiffened a bit.
[21:04] * grahamtriggs bloody stupid internet connection - I'm all out of sync
[21:04] <mdiggory> me too... was that a IRC fork?
[21:04] <richardrodgers> Sorry - have to run. Bye all
[21:04] * richardrodgers (~richardro@dhcp-18-111-12-48.dyn.mit.edu) Quit (Quit: richardrodgers)
[21:05] <tdonohue> yea -- grahamtriggs -- that is being discussed. DuraSpace has another separate JIRA for Fedora/DuraCloud: https://jira.duraspace.org/secure/Dashboard.jspa (it's newer & fancier). We'll be working to move DSpace over there as well soonish (we're currently just trying to find free time to do it)
[21:05] <grahamtriggs> mdiggory: my Skype wouldn't connect either though... but other apps appeared to still be working
[21:06] <tdonohue> meeting is adjourned officially (as PeterDietz said) -- but, I'm still here if there's extra topics to discuss
[21:07] <mhwood> Must go. Thanks all!
[21:07] <tdonohue> not sure what happened to IRC grahamtriggs & mdiggory -- i didn't see it on my end
[21:07] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:34] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[21:53] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 252 seconds)
[21:59] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[22:03] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) Quit (Quit: Page closed)
[22:10] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[22:10] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[22:16] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[22:24] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[23:06] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 276 seconds)
[23:17] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.