Timestamps are in GMT/BST.
[0:08] * ksclarke1 (~kevin@adsl-235-99-153.clt.bellsouth.net) Quit (Quit: Leaving.)
[1:53] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) has joined #duraspace
[5:17] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) Quit (Quit: Leaving.)
[6:31] -hitchcock.freenode.net- *** Looking up your hostname...
[6:31] -hitchcock.freenode.net- *** Checking Ident
[6:31] -hitchcock.freenode.net- *** Found your hostname
[6:31] -hitchcock.freenode.net- *** No Ident response
[6:31] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:31] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:31] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:08] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[9:46] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[9:49] * Mayank (~MnzNotebu@122.163.232.127) Quit (Ping timeout: 252 seconds)
[14:17] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:26] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:50] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) has joined #duraspace
[14:58] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) Quit (Remote host closed the connection)
[15:13] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:16] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:27] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[16:15] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) has joined #duraspace
[16:39] * Mayank (~MnzNotebu@122.163.232.127) has joined #duraspace
[18:59] * cccharles (~user@compy486.uoguelph.ca) has joined #duraspace
[19:49] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[19:52] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) has joined #duraspace
[19:52] <KevinVdV> Hi all
[19:52] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:54] <tdonohue> Hi all, just a reminder that Dspace Developer Mtg starts here at top of the hour. Here's the agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-09
[20:01] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[20:01] <tdonohue> Hi all. DSpace Developer Mtg starts now. We'll begin with a "quick-paced" JIRA Review (2 mins max per issue). Any volunteer to either post issues or summarize?
[20:01] <tdonohue> We'll start from this list of JIRA issues (beginning with DS-717): https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-717+ORDER+BY+key+ASC
[20:01] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:03] <tdonohue> no volunteers to post or summarize issues during JIRA review? Well, I'll just begin with DS-717 and do both then :)
[20:03] <tdonohue> https://jira.duraspace.org/browse/DS-717 : Duplicated template in Kubrick theme
[20:03] <stuartlewis> I'll summarise if you want?
[20:04] <PeterDietz> I'll post, stuart can tally
[20:04] <richardrodgers> +1 with patch DS-717
[20:04] <mhwood> I can do it. I was hoping someone who knows the theme would say which template should survive, but I can pick one.
[20:04] <tdonohue> +1 for DS-717 as well, if we get a patch
[20:05] <stuartlewis> +1 - assign to mhwood?
[20:05] <mhwood> Yes, if no one else claims it, assign to me.
[20:05] <robint> +1. mhwood could you pester the @mire guys to see if they can advise ?
[20:05] <tdonohue> Kubrick was built by TDL (i believe) could talk with scottatm, but it may be that we'll just need to pick whichever template looks the most "correct"
[20:06] <stuartlewis> OK - summary: +4, assign to mhwood?
[20:06] <PeterDietz> https://jira.duraspace.org/browse/DS-720 Solr statistics documentation in DSpace manual and DSDOC is out-of-date, wrong, and inconsistent with dspace.cfg
[20:06] <robint> Why did I say that ? Wrong theme, doh !
[20:06] <mhwood> I'll take 717.
[20:07] <tdonohue> DS-720 - is this resolved, kshepherd? Is there anything left to document?
[20:07] <richardrodgers> definitely needs attention +1
[20:07] <stuartlewis> kshepherd is stuck on the bus at the moment
[20:07] <richardrodgers> no phone irc ;)
[20:08] <mhwood> +1
[20:08] <tdonohue> +1 DS-720, I vote to assign to kshepherd (since he's on a bus) :)
[20:08] <stuartlewis> +1 - looks like it needs to be tidied up.
[20:08] <stuartlewis> Kim will probably be happy to look at it, and if those parameters are still in the code, reassign to @mire
[20:08] <stuartlewis> Summary: +4, assign to kshpeherd
[20:08] <tdonohue> sounds like a good plan.
[20:09] <KevinVdV> Just let us know if there is anything that needs to change on it (I'm one of the @mire guys)
[20:09] <PeterDietz> https://jira.duraspace.org/browse/DS-722 On login screen, keyboard input focus should be set to the first field (E-mail Address) so you don't have to use the mouse (XMLUI)
[20:09] <tdonohue> +1 to DS-722, needs volunteer to implement & test for themes
[20:10] <mhwood> +1
[20:10] <richardrodgers> +1 Andrea has supplied patch
[20:10] <kshepherd> hi all, sorry for lateness
[20:10] <PeterDietz> andrea's patch was for jspui
[20:10] <stuartlewis> Is it theme independent, or per-theme implementation?
[20:10] <PeterDietz> ...that was copy/paste.. ds-561 = jspui, ds-722=xmlui
[20:10] <richardrodgers> Ah PeterDietz - didn't notice
[20:11] <tdonohue> stuartlewis -- not sure, to be honest. I'd guess *independent* of theme, but needs analysis
[20:11] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:11] <tdonohue> volunteer to implement DS-722?
[20:12] <PeterDietz> before i grab it, how does login work when you use SSO, a seperate login page?
[20:12] <stuartlewis> Yes - redirected to an external login
[20:12] <PeterDietz> ...but for the default dspace-based-login, then a little JS to focus on username is fine. I can take this task
[20:12] <stuartlewis> Summary: +3, assign to PeterDietz?
[20:12] <PeterDietz> https://jira.duraspace.org/browse/DS-723 Some Browse code did not take into account the change to Authority values
[20:13] <stuartlewis> grahamtriggs: Can you comment on this?
[20:14] <tdonohue> grahamtriggs: can you provide examples from code? I feel like I'm a little lost without that context
[20:14] <stuartlewis> Assign to Graham, asking for further info?
[20:14] <tdonohue> +1 to assign to grahamtriggs, needs more details (esp. references to areas of code affected)
[20:14] <PeterDietz> i think this was during Graham's marathon code change, so it could be cloudy
[20:15] <PeterDietz> https://jira.duraspace.org/browse/DS-724 createAdministrators() and createSubmitters() should not add policies if the associated group already exists
[20:15] <stuartlewis> Summary: +1, assign to grahamtriggs
[20:16] <richardrodgers> has anyone looked at patch DS-724?
[20:16] <tdonohue> +1 to DS-724, this sounds like a bug to me. Needs a volunteer to analyze & test patch
[20:16] <kshepherd> i'm not sure of the patch, but the issue is reasonable
[20:16] <robint> Not sure if this is a bug.
[20:16] <robint> There is an arguement for always having uniquely named groups associated with collections
[20:17] <PeterDietz> the patch is weird to read since the code was just moved out of an if block
[20:17] <robint> and then add other common groups ijnto those groups.
[20:17] <kshepherd> there doesn't seem to be any test to check for pre-existence of the groups?
[20:17] <kshepherd> ah, true
[20:17] <robint> If you allow common groups you will get Exceptions elsewhere
[20:17] <robint> eg when you try and delete a collection.
[20:17] <tdonohue> any volunteer to analyze this further & comment/report back on whether or not this is a bug?
[20:17] <mhwood> Then Delete needs to be fixed.
[20:18] <robint> mhwood: possibly true.
[20:18] <robint> I'll take it
[20:18] <stuartlewis> Summary: +1, needs more analysis. Assign to robint.
[20:18] <PeterDietz> https://jira.duraspace.org/browse/DS-731 add the capability to indicate a withdraw reason to an item ( tombstone )
[20:19] * tdonohue suggests that we move on to other topics *after* this DS-731 review
[20:20] <PeterDietz> I think the main addition from the patch is being able to withdraw an item, and say either: "Removed at request of author", or "Removed at request of university"
[20:20] <stuartlewis> Sounds like one where UI parity would be advisable?
[20:20] <tdonohue> +1 to the *idea* of a withdrawn item tombstone. The code needs analysis though.
[20:21] <tdonohue> Also, DS-731 seems to be a repeat or very similar to both DS-429 & DS-587
[20:21] <tdonohue> https://jira.duraspace.org/browse/DS-587
[20:21] <tdonohue> https://jira.duraspace.org/browse/DS-429
[20:21] <PeterDietz> I'm wondering if instead of creating new db table, using some internal dspaceMetadataSchema that specifies some embargo/withdraw/reason data
[20:23] <mhwood> +1 good idea, wants study, XMLUI equivalent needed
[20:23] <kshepherd> +1 to the idea
[20:23] <tdonohue> Also, note, DCAT is currently discussing DS-587 (which seems to be this feature request). We may want to link DS-731 up with that, and get a response from DCAT as well: https://wiki.duraspace.org/pages/viewpage.action?pageId=23269796
[20:24] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) has joined #duraspace
[20:24] <stuartlewis> SUmmary: +3, needs more investigation and a volunteer. Note needed about UI parity required.
[20:25] <tdonohue> ok..we'll stop there for today...on to other topics! Thanks stuartlews & PeterDietz for leading that JIRA review
[20:25] <kshepherd> either DS-587 or DS-731 should be closed as a dup... they have the same reporter. 731 seems to go into a bit more detail, but people might already be watching 587
[20:25] <tdonohue> kshepherd -- I agree. we need to minimally link them all together, and then decide which is the "main" one and close the others
[20:26] * JosephRhoads (42beaa61@gateway/web/freenode/ip.66.190.170.97) has joined #duraspace
[20:26] <tdonohue> OK -- next topic. GSoC 2011!
[20:26] <kshepherd> hooray
[20:26] * kshepherd is keen to be a mentor
[20:26] <tdonohue> If you've looked at the agenda, you'll see I'm working on the DuraSpace application. Fedora & DuraCloud are going to suggest projects as well this year!
[20:27] <richardrodgers> excellent
[20:27] <stuartlewis> That's good new.
[20:28] <tdonohue> So, I'd like to suggest we (1) start brainstorming potential projects, and (2) start locating potential mentors I'd like to do both of these primarily on the Wiki at first, I've started to clean up our GSoC area in preparation
[20:28] <tdonohue> DSpace GSoC project ideas should go here: https://wiki.duraspace.org/display/DSPACE/Google+Summer+of+Code+Ideas
[20:29] <tdonohue> If you are interested in volunteering to mentor this year, please add your name here: https://wiki.duraspace.org/display/DSPACE/Current+Google+Summer+of+Code+Projects
[20:30] <tdonohue> Fedora & DuraCloud are going to do their own "ideas" page, and track down their own potential mentors. We'll link everything up via our DuraSpace GSoC Wiki area: https://wiki.duraspace.org/display/DSPACE/Current+Google+Summer+of+Code+Projects
[20:31] <tdonohue> Also, Chris Wilper, Bill Branan & Andrew Woods will help with GSoC Administration Duties -- so, we'll have cross-administration of GSoC from all three projects
[20:32] <tdonohue> (I'll be an Administrator as well, obviously)
[20:32] <tdonohue> So...any initial questions right now, or topics to discuss in regards to GSoC?
[20:32] <kshepherd> how do we feel about projects that we've "done" before?
[20:33] <kshepherd> ie. resurrecting projects that haven't quite been finished or stable enough to get promoted as a module or make it into trunk
[20:33] <tdonohue> kshepherd: do you mean, how do we feel about a "repeat" project on the same topic?
[20:33] <kshepherd> yeah
[20:33] <robint> kshepherd: in favour
[20:33] <mhwood> Sounds more like "follow-through".
[20:34] <kshepherd> i'm mainly thinking of the REST API here
[20:34] <tdonohue> In the past, we've been fine about that, as long as the *new* version is following through (and not redoing the same thing)...
[20:34] <richardrodgers> kshepherd: in favor also
[20:34] <stuartlewis> +1 too
[20:34] <tdonohue> yea, REST API has been a project in both 2009 and 2010
[20:34] <kshepherd> i'm pretty keen to help get something really good by the end of this gsoc term
[20:34] <mhwood> Yes, let's not lose good work.
[20:34] <kshepherd> not sure if it should be starting from scratch or building on previous work
[20:34] <stuartlewis> I'd like to see it started again, rather than continued or old code picked up.
[20:34] <mdiggory> I would work on trying to keep the project pool aligned with the Development Areas and Development Proposals...
[20:35] <tdonohue> I'll also mention that I'd *REALLY* like to see REST API in DSpace 1.8.0 -- whether that means a GSoC project, or finding one of us to complete it
[20:35] <kshepherd> yeah
[20:35] <mdiggory> Bojan really wants to see this as well
[20:35] <kshepherd> i'm just not so sure of all the odd sakai dependencies in the existing REST work
[20:35] <mdiggory> and so you have a resources there still to assist
[20:35] <kshepherd> but i know bojan worked hard
[20:36] <stuartlewis> If it isn't completed in two years, will a third complete it?
[20:36] <tdonohue> Bojan continues to work hard (see his recent email to dspace-tech)...he's still supporting REST API on his own time
[20:36] <mdiggory> we pull tehm into our repo if neccessary
[20:37] <kshepherd> the last time i tested, it still wasn't really functional, even for read-only
[20:37] <kshepherd> maybe i need to test again
[20:37] <stuartlewis> Eitherway - I think it is critical that it has a DSpace mentor, not a Sakai mentor this year.
[20:37] <tdonohue> stuartlewis -- my worry as well. A part of me feels REST API needs "adopting" by one or more committers. But, I wouldn't be against having another project, as long as we make sure we gear it towards getting something "usable" (even if it's beta quality) for 1.8
[20:38] <stuartlewis> Yeah - I'd like to see it started again, very minimal / small / simple, get it in 1.8 and working, and then improve it over time based on a good framework.
[20:38] <tdonohue> +1 to that... any REST API will need updates as more use cases appear, etc
[20:38] <tdonohue> ok...other specific things to talk about with regards to GSoC 2011?
[20:39] <richardrodgers> stuartlewis: JAX-RS?
[20:39] <kshepherd> richardrodgers: that would be my preference
[20:39] <kshepherd> so easy
[20:40] <stuartlewis> Yes - would be an excellent candidate.
[20:41] <tdonohue> So, quick question while on this topic -- do any of us have time to spend on REST API work for 1.8? Even if it's reimplementing using JAX-RS (which would be fine by me, to be honest)? If not -- maybe we do need a GSoC project there...
[20:41] <mdiggory> ok, sorry... trying to tag along in the conversation.
[20:41] <stuartlewis> GSoC should finish in time for 1.8?
[20:42] <mdiggory> BOjan was mentored by both Myself and Aaron last year,
[20:42] <stuartlewis> So if we have a couple of good mentors on this, and the interest of the development community, and the intention of it being a core deliverable of 1.8, that will give us a good start.
[20:42] <tdonohue> ugh...actually, no. :) GSoC finishes on Aug 22 and the 1.8.0 "Feature Freeze" is Aug 19
[20:43] <kshepherd> hmm
[20:43] <stuartlewis> Would it be sensible to revise that slightly, to fit with GSoC?
[20:43] <mdiggory> I'm ok with choosing standardized approaches for implementing REST, but I expect that even in that vein, you will find numerous possible solutions
[20:43] <kshepherd> mdiggory: yeah for sure..
[20:43] <richardrodgers> yea, we could stretch for meritorious GSOC stuff....
[20:43] <mdiggory> If, GSoC is approached more directly within the release process, it can fit
[20:44] <mdiggory> so for instance, approaching design and coding with incremental additions to trunk...
[20:44] <stuartlewis> +1
[20:45] <kshepherd> yep +1, and keeping everyone in the loop with those incremental additions so we cna get early testing in
[20:45] <kshepherd> s/cna/can/
[20:45] <PeterDietz> I recall there were some performance faults with certain dspace components that prevented rest from being a fit for 1.7, perhaps bugs for dspace-api components can be filled, and fixed by dspace committers. (its possible this was not the case though)
[20:45] <PeterDietz> /s/filled/filed/
[20:46] <tdonohue> I agree with mdiggory -- if the project is approached differently, it could fit into 1.8.0. But, it would need more supervision of mentors (obviously), and more involvement/feedback from our developers in general (as does any new feature)
[20:46] <stuartlewis> Yes - so we need to really group together an 'adopt' this if we want to see it in 1.8 - and I think it is essential we get a restfull API soon. So count me in :)
[20:46] <kshepherd> PeterDietz: yeah... i'm not totally against using the existing code for REST. i just don't understand all the sakai dependencies or the way some of the stuff got implemented re: entities
[20:47] <kshepherd> there were a few things that were working.. listing item IDs in a collection, etc.
[20:47] <mdiggory> It part of something we need to change about our own community process as well, robint an PeterDietz have both spoken out more for getting change into trunk earlier and allowing for some "breakage" to promote actvitiy and progress
[20:49] <mdiggory> Even I am guilty of spending months perfecting a solution only to have to spend significant time adjusting/repairing for other changes getting in before mine
[20:49] <kshepherd> i'm ok with trunk breakage
[20:49] <kshepherd> but i believe it conflicts with current 'committer guidelines'
[20:49] <mdiggory> ok, because I might just break it soon ;-)
[20:49] <PeterDietz> i know mdiggory is down with some trunk breakage: https://bamboo.duraspace.org/browse/DST-TRUNK
[20:49] <richardrodgers> I guess I'd be cautious about student & trunk-direct - it may disinhibit experimental work...
[20:49] <stuartlewis> So for a project such as rest api, where the intention is for inclusion and it is quite modular and separate, do we start with the assumption that student access to trunk is the norm after coding begins and we know they know how to drive svn?
[20:49] <kshepherd> https://wiki.duraspace.org/display/DSPACE/Guidelines+for+Committing
[20:50] <kshepherd> says "No incomplete features in Trunk, ever"
[20:50] <tdonohue> i'm ok with trunk breakage as long as it doesn't *stick around* for long periods of time (i.e. a few hours or a day of breakage = OK, but a week could cause issues amongst us all)
[20:50] <mdiggory> PeterDietz: ha
[20:50] * PeterDietz thinks GSoc students would be perfect guinea pigs for github
[20:50] <mhwood> tdonohue++ Broken trunk is *urgent*.
[20:50] <tdonohue> We can change our "Guidelines for Committing" if there are good reasons to
[20:50] <kshepherd> mm, i'm a git/github convert since a few weeks ago
[20:51] <mdiggory> doh, how'd that get in trunk pfft.
[20:51] <tdonohue> I'm wanting to become a 'github' convert, once I find some spare cycles :)
[20:51] <mdiggory> oh, the copies got recoreded into trunk as deletions. that wasn't supposed to happen just yet
[20:52] <tdonohue> Ok...are we good on GSoC then? Sounds like this is slowing a bit. REST API discussion will likely continue some next week (when I bring up a proposed DSpace Roadmap to 2.0)
[20:52] <robint> At the risk of being mistaken for mdiggory, a more modularised approach may mean that trunk gets touched less
[20:53] <mdiggory> tdonohue: agreed, getting to work on removing my foot from my mouth ;-)
[20:54] * stuartlewis must leave now - meeting in a few minutes. Thanks and Goodbye.
[20:54] <tdonohue> Next topic: (I haven't discussed this with robint yet, but) I'm starting to think we should start to assigning one or more "Backup Release Coordinators" again. We used to do this, but it fell off somewhere along the way
[20:54] <kshepherd> same
[20:54] <mdiggory> robint: yes, and that there are contracts for interfaces that shouldn't be touched within say, a maintence branch
[20:54] <kshepherd> cheers all
[20:54] <robint> tdonohue: Certainly no complaints from me :)
[20:54] <tdonohue> Main reason for having a "Backup Release Coordinator" is that the RC has someone else to collaborate with. Also, it gets *more of us* familiar with Maven release processes
[20:55] <richardrodgers> +1 backup - we do need to get broader competence
[20:55] <mdiggory> tdonohue: I think, like you suggested we've just been volunteering ourselves for that role informally the last few releases
[20:55] <mdiggory> the backup should / could be someone who performed a recent release
[20:55] <tdonohue> So, I'd like to put out a call for a Backup Release Coordinator. If you are interested, please let Robin & I know. I'd like to avoid mdiggory & I always having to act as "backup" :)
[20:56] <robint> I would add it could be on a best efforts basis with no firm time commitment
[20:56] <tdonohue> I'd say the "backup" need not be someone who performed a recent release -- but it doesn't hurt :)
[20:56] <mdiggory> "Release Mentor?"
[20:57] <tdonohue> +1 -- I'd agree, no firm time commitment. Generally, the "backup" should just act in a supporting role for the Release Coordinator. The "backup" should also be sure to learn the release processes, so that he/she can provide help when the Release Coordinator needs help
[20:58] <tdonohue> (obviously, others of us who've done releases before will also continue to provide support as needed too...but, this gets more of us familiar with releases in general)
[20:58] <PeterDietz> I do have a few notes to add for 1.7.1, as in bugs that should get looked at
[20:59] <tdonohue> ok...sounds like we're all generally in favor. I'll send a request for a backup to dspace-commit
[20:59] <tdonohue> go ahead, PeterDietz with 1.7.1 updates
[20:59] <PeterDietz> ksheperd needs spring-experts to verify his solution to SWORD+Discovery incompatibility (i.e. other webapps need to become sprung) https://jira.duraspace.org/browse/DS-785
[20:59] <mdiggory> this is why I suggest (not as a formal policy) that the previous release manager makes the best candidate to provide backup support.
[21:00] <PeterDietz> 1.7.0 may have broken things with https://jira.duraspace.org/browse/DS-821 AbstractMETSIngester creates an item before adding descriptive metadata
[21:00] <mdiggory> did kshepherd already leave?
[21:00] <richardrodgers> yes i think so
[21:00] <tdonohue> mdiggory: although that's "ideal", I'm hesitant to require it, as it means volunteering for *one* release would mean you are also volunteering for the next one :)
[21:00] <PeterDietz> yeah, he and stuart had a meeting
[21:00] <PeterDietz> Also, I'm willing to let slide things that have been broken with 1.5, 1.6, etc and somewhat focus and bugs created by 1.7.
[21:00] <tdonohue> DS-821 status - I'm on it, but I need more time in my day :)
[21:01] <tdonohue> If anyone wants to help *test* DS-821 (I have a potential fix, which I haven't posted quite yet), please let me know!
[21:01] <mdiggory> Thats the tao of volunteering.
[21:01] <mdiggory> once you start, you can't stop... you want to do more
[21:02] <PeterDietz> I've finally gotten the hang of badgering people to commit stuff, and reviewing jira for bugs, so I'll toss my hat in the ring to be robint's sidekick for 1.8
[21:02] <mdiggory> how could you add descriptive metadata to an item before creating it?
[21:02] <richardrodgers> Thanks PeterDietz !
[21:02] <mdiggory> kinda a chicken and egg
[21:03] <PeterDietz> We are waiting to hear more from the OP about searching LDAP - https://jira.duraspace.org/browse/DS-835, it could either be a mis-configuration, or an introduced bug, I haven't reviewed it
[21:03] <tdonohue> mdiggory -- title of DS-821 should say "AbstractMETSIngester *installs* an item before adding descriptive metadata"
[21:03] <richardrodgers> tdonohue: I can look at DS-821...
[21:03] <mdiggory> yes, just read it...
[21:04] <robint> PeterDietz: much appreciated. I'll try and keep the badgering to a minimum :)
[21:04] <tdonohue> richardrodgers -- would appreciate it. I have a potential fix, and can post as a patch to DS-821. But, it's as of yet untested, and I haven't found time to do so this week (with GSoC, etc)
[21:04] <richardrodgers> I'll pick up the patch then, tdonohue
[21:05] <tdonohue> sounds good, I'll post patch later today (hopefully) and ping you
[21:05] <mdiggory> ok, while I got you here, and I've managed to break the trunk last night I want to get a feel for if I should just follow through with the rest of the commit to support the dspace-model project in the dspace-api or if I should roll back the deletions.
[21:06] <tdonohue> Ok. One last thing I wanted to mention today. U of Minho just posted a series of patches of all the various "addons" they've built in recent years. There's some interesting stuff there for us to look at. So, I'd like to encourage anyone who is interested to start testing/evaluating their work. Could be "easy" features for 1.8, but definitely need review & discussion
[21:06] <mdiggory> changes will (1) move 3-4 Interfaces and the Constants class to dspace-model, then add interfaces to all the DSpaceObject class signatures
[21:07] <richardrodgers> I guess I'd like to know more, before seeing it in trunk, broken or not
[21:07] <richardrodgers> Is it in a branch/sandbox anywhere?
[21:07] <robint> just for info - is it Uni of Minho ? or the commercial offspring ?
[21:07] <robint> not that it matters
[21:08] <mdiggory> richardrodgers: its in my workspace ATM
[21:08] <mdiggory> I can produce a patch and post it.
[21:08] <richardrodgers> Could you publish it somewhere?
[21:08] <tdonohue> robint, I think it's actually *both*. patches are from U of Minho & RCAAP
[21:08] <mdiggory> the changes are meant to be very lightweight for the DSpaceObject model itself
[21:08] <richardrodgers> mdiggory: patch is fine too
[21:09] <robint> I'm all in favour of encouraging them, so I'll try and look time permitting
[21:09] <mdiggory> it intorduces the external Interfaces and services to get at the DSpace resources, which then allows you addon to not have to depend directly on dspace-api
[21:09] <mdiggory> it will allow us to move dspace-statistics and dspace-discovery back to the "modules" workspace
[21:10] <tdonohue> robint: I'd appreciate it. I think the "OAI-Extended" patch (DS-829) is especially interesting, as it makes us compliant with DRIVER and OpenAIRE Guidelines (which I know may be more important in Europe than here in the USA, but it's still worth doing)
[21:11] <robint> mdiggory: if we are commited to the new architecture I think we need to be a bit gungho or it will never come to reality
[21:11] <mdiggory> likewise, over a couple versions we can rewrite the dspace-xmlui and other webapps to rely on dspace-model, allowing us to attain the "asyncronous release" process in trunk... or, more accurately, maintain projects used by trunk outside of trunk
[21:12] <mdiggory> all this is being borrowed directly from the DAO prototype (but with some changes / simplification on my part)
[21:12] <robint> Unfortunately got to go. Cheers all.
[21:12] * tdonohue notes we're over time. Feel free to head out if you need to. Next week is a meeting on DSpace RoadMap to 2.0 (I will post a proposed RoadMap later this week). I'm sticking around for what mdiggory is talking about.
[21:12] <mhwood> Actually we wind up with a whole grove of trunks.
[21:12] <mdiggory> the objective is to get this in so that the tool can be used by others in the rest of the work for 1.8
[21:12] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:13] <mdiggory> ok.. I"m going to post a small sample of the rest of the changes in a pastebin...
[21:16] <richardrodgers> I have to go - but I really would like a way of reviewing a change this big - I had some large issues with the DAO prototype. Can it not be published somewhere?
[21:16] <richardrodgers> Bye all
[21:16] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:17] <mdiggory> Yes... I was creating a JIRA ticket just before I realized the trunk was broke...
[21:17] <mhwood> I think you need to define "published" a little more precisely.
[21:18] <mdiggory> This is the patch of the "Bridge" shim that makes the DSpaceObject static methods look like they are supported by a DAO
[21:18] <mdiggory> http://pastebin.com/Mm7jKAzp
[21:18] <mdiggory> it is a separate dspace-impl project in trunk atm, but doesn't need to be.
[21:19] <mdiggory> all it does is delegate CRUD DAO calls to the original DSpaceObject that the static method exists on
[21:19] <mdiggory> next patch coming...
[21:22] <mdiggory> These are the signatures applied to the DSpaceObjects...
[21:22] <mdiggory> http://pastebin.com/rze8DLsJ
[21:25] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) Quit (Quit: KevinVdV)
[21:26] <mdiggory> But it also includes a change to DCValue... making it inherit MetadataValue and moving the exposed public fields into it
[21:26] <mdiggory> this will allow us to redo any code that uses DCValue to use MetadataValue and drop that class finally from the code
[21:27] <mhwood> Does that mean that eventually we wind up distributing @Deprecated from DCValue over all the stuff that moved into MetadataValue?
[21:28] <mdiggory> no, DCValue would be removed in favor of MetadataValue
[21:28] <mhwood> Actually I see that the answer is "not eventually; now".
[21:30] <mhwood> So (most of) the deprecation warnings don't go away yet, but we can squish them one field at a time. OK.
[21:32] <mdiggory> Yes, the path becomes obvious, we can leave the fields there and just migrate stuff completely, but I needed MetadataValue to be returned by the IItem.java api, not DCValue
[21:32] <mdiggory> because we need the API, not some concrete class with exposed fields in it
[21:33] <mhwood> OK, the first step in really replacing DCValue is that something starts returning MetadataValue.
[21:34] <mdiggory> right, in fact it starts returning IMetadataStatement
[21:34] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-model/trunk/src/main/java/org/dspace/services/dao/model/IMetadataStatement.java
[21:35] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-model/trunk/src/main/java/org/dspace/services/dao/model/IItem.java
[21:35] <mdiggory> IMetadataStatement[] getMetadata(String mdString);
[21:37] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[21:37] <mhwood> I see. Re-lurking now.
[21:37] <mdiggory> if you look at line 366 of http://pastebin.com/rze8DLsJ you will see that we make Item return MetadataValue objects instead of DCValue objects
[21:42] * hhhh (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[21:47] <mdiggory> one challenge I do see with overhauling the DCValue / Metadata is that in some placed the DCValue are created rather loosely, while in others MetadataValue / MetadataField assures that we care getting valid Registry Metadata Fields.
[21:48] <mhwood> So the change is good from that POV too. :-/
[21:48] <mdiggory> right, cleaning that up means the code in DSpace needs to properly look up the field.
[21:49] <mdiggory> not just spooge out whatever is in the sql table or accepting whatever came from the html form / packager.
[21:50] * hhhh (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:50] <mdiggory> but doing so sets the stage for us creating a formal authority controll api as well... we can begin to "type" the values, and with authority keys, possibly provide pointers out to "authority records"
[21:51] <mdiggory> but thats further down the road... right now the goal is to get the api extracted
[21:54] <stuartlewis> Back now.
[21:55] <stuartlewis> I see someone mentioned DS-835 (LDAP not working in 1.7). I've not yet had any feedback from the reporter, and it works for me, so shall I close it, and leave a message about being welcome to re-open it?
[21:55] <stuartlewis> https://jira.duraspace.org/browse/DS-835
[21:58] <tdonohue> stuartlewis -- I'd say close DS-835 with a message saying it can be reopened later as needed (if there is a bug). In general, I'm in favor of closing issues quickly when possible, so they don't sit around open forever :)
[21:59] <stuartlewis> Ok - will do so.
[21:59] <kshepherd> mdiggory: i'm back
[21:59] <stuartlewis> Thanks for the METS patch - I'll try and find time to test it next week. Pester me if I don't :)
[21:59] <mdiggory> hey...
[22:01] <tdonohue> will do, stuartlewis... I quickly created that DS-821 fix monday morning, but have been pulled away since then, and haven't had a chance to test it as well as I want to myself. So, I figured I'd try to "crowdsource" some of the testing. I hope to get back to it later this week to do my own further testing
[22:03] <mhwood> Must go. Thanks....
[22:03] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Remote host closed the connection)
[22:06] <kshepherd> mdiggory: RE: spring/services/sword/slf4j/etc, i think i just need to release another dspace-solr artifact with fixed slf4j dependencies?
[22:09] <mdiggory> ok, I thought you had worked out the revisions and determined it was a Servicemnager startup issue, note you do not need to do what your doing in the ticket with a spring application context to start the service manager, whats done with creating the applicationContext is done in xmlui and jspui to have UsageEvents recordable in the UI.
[22:10] <mdiggory> SWORD and other apps do not use UsageEvents and don't need it enabled
[22:10] <kshepherd> hmm
[22:10] <kshepherd> maybe i need to revisit
[22:10] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[22:11] <kshepherd> if i don't do the spring stuff in sword, i get dspace kernel init exceptions whenever it tries to fire a "new item" usage event
[22:12] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 250 seconds)
[22:12] * stuartlewis_ is now known as stuartlewis
[22:13] <mdiggory> ok, that sounds more like a bug in the Event system, possibly cause because there are no EventListeners?
[22:14] <mdiggory> but, also sounds like your getting the spring application context in xmlui and jspui confused with the context listener in the web.xml that starts the kernel
[22:15] <mdiggory> <!-- kernel start listener (from impl), starts up the kernel for standalong webapps -->
[22:15] <mdiggory> <listener>
[22:15] <mdiggory> <listener-class>org.dspace.servicemanager.servlet.DSpaceKernelServletContextListener</listener-class>
[22:15] <mdiggory> </listener>
[22:15] <kshepherd> that sounds likely ;) all i know is that if i configure SWORD the way i have, i can ingest new items, and have the Events fired so that those new items appear in teh discovery index. if i don't, i get an exception and the item is never ingested
[22:16] <kshepherd> i'll start again and try to simplify things so that i'm just configuring the context listener
[22:16] <mdiggory> Thats the problem with having two different event systems, you don't know which is being referred to
[22:16] <mdiggory> configuring the Discovery Consumer is in the dspace.cfg and not the webapplication
[22:17] <mdiggory> try just using the listener and not all the other spring stuff and see if that is sufficient
[22:17] <kshepherd> yes, understood about the consumer config in dspac.ecfg
[22:17] <kshepherd> will do, cheers
[22:23] <kshepherd> mdiggory: hope i didn't offend re: RESTful stuff, i just have trouble following the current work -- i'll make an effort to figure it out soon
[22:24] <mdiggory> no offense, if I'm offended, its usually me thats wrong ;-)
[22:26] * stuartlewis is offended that you weren't offended. We'll have to try harder next time :p
[22:27] <stuartlewis> We're wondering if we need to agree before GSoC what solution we want for an api (as the development community) to help ensure the success of the project getting into 1.8.
[22:27] <mdiggory> :x
[22:27] <stuartlewis> ;)
[22:27] <stuartlewis> It would then be more of an implementation project than an R&D project, but hopefully we'll find a student who that would suit.
[22:33] <mdiggory> ok.. think I fixed all the breakage
[22:36] <mdiggory> tdonohue: I'll volunteer to give this time for a more proper review by the community on next wednesday
[22:37] <tdonohue> stuartlewis -- is this specific to assuming we have a continuation REST API project for GSoC? If so, I'd agree that such a project (if the goal was making it into 1.8) would need more immediate feedback from the developers & even a suggested implementation
[22:38] <tdonohue> we'd also need to make certain that such a GSoC project was "highly controlled" (in that we would need one or more highly active committers as mentors, and we'd need even more updates on status throughout GSoC)
[22:38] <mdiggory> I swear, since switching to IDEA, I've had more errors with svn commits than I ever did with Eclipse
[22:39] <tdonohue> not good to hear, mdiggory, as I just switched to IDEA from NetBeans :)
[22:40] <tdonohue> mdiggory -- as for next week, are you saying you'll have your model refactoring code posted for review? Or are you wanting to lead a discussion in the meeting itself? or both?
[22:41] <mdiggory> You have to be brutally aware of what is going into a changeset when you commit... I thought I was being diligent, apparently if you do a drag/drop move of a file, rather than just treating it as a copy into the new location when commiting the new location, it also traces back and commits the deletion from the old location as well
[22:43] <mdiggory> yes, that I will have a selection of patches outlining the changes, I'm not creating a branch because the actually core code changes are minimal and should be reviewed conceptually, not built and run... its a refactoring, not new features.
[22:44] <tdonohue> All -- I added a small clarification to the "No incomplete features in Trunk, ever" rule of our Guidelines for Committing, based on today's discussion. Feedback welcome :) https://wiki.duraspace.org/display/DSPACE/Guidelines+for+Committing
[22:44] <tdonohue> mdiggory -- sounds good. Please post the patches to JIRA, so that we can better track them :)
[22:45] <mdiggory> I think what we should say about trunk is that your changes have to be well thought out before attempting them, not half-baked experiments on trunk.
[22:49] <mdiggory> for instance, the patch I provide on trunk may encounter a few straggling issues, thats ok if the goal is to get the feature into place early. In fact, thats generally how changes currently work, we aren't changing how we do things, we are making our rules more accurate to our actual process.
[22:50] <stuartlewis> mdiggory: Yes - that's possibly my biggest issue with IDEA - it tries to be too clever sometimes.
[22:52] <tdonohue> mdiggory -- not sure I understand the difference between what you are saying and what is in our guidelines? A "few straggling issues" is fine...the point in the guidelines is that you should NOT be developing a larger feature primarily out of trunk (until it is stable enough / ready enough for more eyes/testing).
[22:53] <tdonohue> maybe that isn't clear enough in those guidelines? if not, we can obviously change the wording :)
[22:58] <mdiggory> maybe we should just say "Go ahead, break the trunk, I dare ya! Make my day, sucker."
[22:59] <tdonohue> haha..yea, and then one of us will accidentally commit major "breakage" just before heading off for a week or month long vacation...thus leaving the rest of us to clean up the mess :)
[23:00] <tdonohue> if you want to "break trunk" so much, why not switch over to Git? Then you can break your own "trunk" as much as you wish, without effecting everyone else :)
[23:06] * stuartlewis has too much of a teenage boy sense of humour
[23:06] <kshepherd> stuartlewis: you won't find the git jargon any better
[23:06] <kshepherd> "stop pulling that thing, it'll fall off"
[23:07] * kshepherd remembers this channel is logged
[23:07] <kshepherd> seriously though, git can suffer the same problem
[23:07] * stuartlewis is now known as anonmous-can-say
[23:07] <anonmous-can-say> That's better ;)
[23:07] <tdonohue> haha ... um, yea. we are logging :)
[23:07] * anonmous-can-say is now known as stuartlewis
[23:07] <kshepherd> we all fork our own repos, spend ages perfecting our solutions then end up with a bunch of merge conflicts when we submit pull requests
[23:08] <kshepherd> so github doesn't inherently solve the problem that a lot of us (especially me!) sit on patches/commits too long
[23:08] <stuartlewis> And it doesn't solve the problem of finding time to peer-review the patch, and to test it.
[23:09] <kshepherd> might make modules easier to work with though? (sub-modules)
[23:09] * stuartlewis has noting against git BTW, I use it myself: http://github.com/stuartlewis/
[23:09] <stuartlewis> nothing*
[23:09] <stuartlewis> Submodules are one of the things that cause me most pain.
[23:09] <kshepherd> oh
[23:09] <kshepherd> i'll shut up then ;)
[23:09] <tdonohue> yea .. no technology can completely solve what is actually a social problem (sharing/reviewing, that whole feedback loop)
[23:09] <stuartlewis> EasyDeposit has swordapp-php-library as a submodule.
[23:10] <stuartlewis> (Pain that is probably mostly self-inflicted probably!)
[23:14] <tdonohue> well...gotta head out now & start some dinner preparation. have a good one, all!
[23:15] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[23:29] <kshepherd> stats on demo.dspace.org hasn't been working for a while?
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.