Below is the transcript of a committer's meeting held on #duraspace at irc.freenode.net at 20:00 GMT on September 2, 2009.
We intend to hold the next meeting on #duraspace September 9 at 18:00 GMT, in conjuction with a jira issue review meeting. The issue review will take place from 18:00 to 19:00, and the committer meeting from 19:00 to 2:00. The #duraspace channel is logged, you can see past meetings (including Fedora Commons meetings as well) at http://www.duraspace.org/irclogs/ You can see the upcoming (weekly) schedule as well as other DSpace developer events at: http://www.google.com/calendar/embed?src=3mfp5qsv0kejvsbh558lmshujk%40group.calendar.google.com Or on the DuraSpace public calendar at: http://www.google.com/calendar/hosted/fedora-commons.org/embed?src=fedora-commons.org_o5iransoopr4i05f7ajpkab7ms%40group.calendar.google.com Anyone is welcome to attend. Meeting Summary: Work towards embargoes, statistics (and event models) for 1.6. Discussion of DSpace modules independent of version. Transcript: [16:02] * rrodgers (n=rrodg...@dhcp-18-111-15-222.dyn.mit.edu) has joined #duraspace [16:03] <stuartlewis> Are we supposed to be having a meeting now? [16:03] * mdiggory (n=mdigg...@64.50.88.162.ptr.us.xo.net) has joined #duraspace [16:03] <mdiggory> Hello [16:04] <rrodgers> (so can we officially now start dumping work on tdonohue ? ;) ) [16:04] * bollini (n=chatz...@host142-190-dynamic.17-87-r.retail.telecomitalia.it) has joined #duraspace [16:04] <mdiggory> :-) [16:04] <tdonohue> rrodgers: Eeek no! [16:04] <tdonohue> i'm holding out as long as I can... :) [16:05] <bollini> hi all [16:05] <tdonohue> I've got too much transition work going on locally these days ;) though I'm looking forward to it being done, so I can concentrate on Dspace/DuraSpace [16:06] <rrodgers> anyway, got a msg that bradmc can;t attend, so one of us should moderate [16:07] <mdiggory> I assume it will be predominantly 1.6, can we volunteer stuartlewis [16:07] <mdiggory> ;-) [16:07] <rrodgers> I like your thinking [16:07] <stuartlewis> Not sure I do! :) [16:07] <tdonohue> in any case, we can start with agenda items...right? [16:07] <mdiggory> I have to leave in about 30 minutes so I'm not a great candidate [16:08] <bollini> I'm too [16:08] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer)) [16:08] <stuartlewis> 1) 1.6 - stats and embargoes [16:08] <stuartlewis> 2) 1.6 release planning [16:08] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace [16:08] <mdiggory> me/ thinks this could also be tdonohue's passage of initiation [16:08] <stuartlewis> Any other agenda items? [16:09] <tdonohue> sure, i'm fine pushing the agenda along...though it sounds like most of it is going to be stuartlewis led w/1.6 [16:09] <mdiggory> (1) is why I'm here... [16:09] <stuartlewis> mdiggory: No, we'll make sure his initiation takes place late at night in Gothenburg...! :) [16:09] <mdiggory> hehehe [16:09] * tdonohue is not sure he likes where this is going :) [16:09] <stuartlewis> Any other agenda items? [16:10] <rrodgers> JIRA? [16:10] <stuartlewis> JIRA cleanup? [16:10] <rrodgers> yes - not sure there is much to say [16:10] <stuartlewis> No -seems to be going well. Will be good when the duraspace intern gets the time to action all the decisions. [16:11] <tdonohue> agreed [16:11] <rrodgers> Will one more session suffice? [16:11] <stuartlewis> At the rate we're going, possibly not. [16:11] <stuartlewis> What we could do, is skip any issues that are assigned to people. [16:12] <stuartlewis> So if you have any assigned that you don't want, unassign yourself, and vice versa. [16:12] <rrodgers> I ask, because if we want follow-on before code freeze, it might be tight... [16:12] <stuartlewis> Yes :( [16:12] <mdiggory> sounds like we could use an update to the wiki concerning which have been covered, which are owned and which still need review [16:12] <bollini> what is the mean of code freeze exactly? [16:13] <mdiggory> code-freeze means no more new features may be added [16:13] <rrodgers> Well, traditionally one still allows bug fixes, but not destabilizing new features [16:13] <mdiggory> and we move into an iteration of testing [16:13] <bollini> features scheduled for 1.6 but not completed before...? [16:13] <stuartlewis> Do we think we can aim for an end of September code freeze? [16:14] <tdonohue> yes, if we want a beta by DSUG in Oct, we probably need an end of Sept code freeze [16:14] <stuartlewis> Major missing components (which need to be in 1.6 rather than 1.6.1) are embargoes and stats. [16:14] <mdiggory> possibly, if we can get resolution on outstanding new features like stats by then [16:14] <stuartlewis> Ok - lets talk about those. Embargoes first... [16:14] <mdiggory> stuartlewis: stats is not missing... its in process [16:15] <rrodgers> I have heard no daminng words about embargo, so I could check in soon [16:15] <stuartlewis> rrodgers: How are the embargoes going? Any indication of a date when they'll be ready and commited? [16:15] <stuartlewis> middogry: Sorry - missing = missing from svn [16:15] <stuartlewis> rrodgers: Excellent news. Thanks. [16:15] <mdiggory> in svn, not in trunk... [16:16] <stuartlewis> Stats then.... [16:16] <stuartlewis> WHat are the outstanding issues we need to decide Mark? [16:16] <kshepherd> rrodgers: the simple implementation i tested worked perfectly.. [16:16] <mdiggory> Ok, per stats... there are two topics of interest [16:16] <rrodgers> Remember that it's really a framework, not a canned solution. I'm hoping we will have 2 or 3 sample implementations [16:16] <mdiggory> UsageEvent/Services... Graham present issues with using services and caching. [16:16] <rrodgers> one from Harvard, maybe one from kshepherd [16:17] <tdonohue> rrodgers: but, does that mean there will still be something "out-of-the-box" or no? [16:17] <mdiggory> I consulted with Aaron concerning this and we determined that the only caching that was being done was at the request level [16:17] <mdiggory> ok, one topic at a time? [16:17] <tdonohue> (sorry...we're on to stats...we can go back to embaro afterwards) [16:17] <tdonohue> yep [16:17] <tdonohue> go one mdiggory [16:18] <tdonohue> go on [16:18] <mdiggory> dspace-services uses ehcache to cache request objects during the request cycle, this is all [16:18] <mdiggory> it doesn't do caching of any session level or DSpaceObjects, thus there is no replication [16:19] <mdiggory> the request is cached so that it can be referenced easily during the transactional window [16:19] <mdiggory> and released at the end of the request cycle (by the servlet filter/etc [16:19] <rrodgers> like DS 1 context cache? [16:20] <mdiggory> Yes, somewhat [16:21] <mdiggory> explicitly for RequetCache, there are other caching options "scopes" available, but they are unused in dspace-services [16:21] <mdiggory> they are used in DSpace 2.0 User services aand Session services [16:21] <mdiggory> but thes are not provided in the build I created for use in 1.x [16:22] <stuartlewis> So is there a decision that we have to make? [16:23] <mdiggory> Yes, services vs original 1.x code + alterations to support easier transfer of DSpaceObjects/State and multiple UsageEvent Consumers [16:23] <rrodgers> how extensive would the alterations be? [16:24] <stuartlewis> What are the pros / cons of each? [16:24] <mdiggory> I.E. either we adopt services, or we tweak 1.x to make it more like EventService [16:24] <mhwood> Multiple consumers appears to be a fairly small change. [16:24] <mdiggory> we have a patch ben_atmire has done to work with... changes look like.... [16:25] <ben_atmire> the patch I created simply chained all consumers after each other [16:25] <mdiggory> In either case... More hooks in the JSPUI and XMLUI to generate Usage Events (as seen in the imho statistics code [16:26] <rrodgers> Have we quantified this UI work? days, weeks? [16:26] <mdiggory> UsageEvent needs to have its method signatures changed to hold DSpaceOBject and HttpRequest Objects [16:26] <mdiggory> rrodgers: Most of this work is done in both cases, what we have are two approaches that we are trying to decide between [16:27] <stuartlewis> mdiggory: Do you have a preference? [16:27] <tdonohue> so, going back to what stuart said, I'm not sure i understand the full pros/cons of the choices [16:27] <mdiggory> My preference (given my research and planned presentation work for DSUG) is dspace-services [16:27] <rrodgers> mdiggory: noted, I was just worried about resources in the 1.6 timeframe [16:28] <bollini> I have not looked at this code yet but if we can move towards to 2.0 architecture (services) this could be great [16:28] <stuartlewis> Is it do-able in the next 4 weeks? [16:28] <mdiggory> IMO either is doable in 4 weeks [16:29] <mdiggory> challenges are not implementation, challenges are acceptance and testing by the community [16:29] <stuartlewis> How seamless a change would services be to joe public sys admin? [16:29] <tdonohue> what sort of challenges do you see in acceptance? Is it in migrating existing stats systems (minho, etc) over to use this one? [16:30] <mdiggory> Services are configured in ServiceManager, not in DSpace.cfg [16:30] <stuartlewis> What does that mean in practice? [16:30] <mdiggory> tdonohue: the challenges I see with migrating Minho are that I am unaware how they integrate with the UI beyond the UsageEvent level. [16:31] <bollini> are you talking about spring configuration files right? [16:31] <mdiggory> Yes and No... [16:32] <mdiggory> Configuring the DSpace ServiceManager can be done in Spring, or it can be done programatically. In the cases I careated, it is configured in a Spring applicationContext file stored within either the XMLUI or JSPUI and initiatlized in the servlet lifecycle [16:32] <mdiggory> in XMLUI it is the same applicationContext.xml utilized by Cocoon [16:33] <ben_atmire> but this is something that's preconfigured, and most installations don't need to worry about it? [16:33] <tdonohue> this is sounding too complex for "joe sys admin"... [16:34] <bollini> tdonohue: I'm not sure about this... there are a lot of examples of spring configuration files out of there [16:34] <mdiggory> ben_atmire: yes, it is preconfigured, and is not any further out of the reach of Joe System Admin than applying crazy patches maintained in a S.F. tracker [16:35] <mhwood> As I understand it, you wouldn't need to touch the config. unless you want to plug in something else (or additional). [16:35] <mdiggory> sorry, meant to also address that to tdonohue [16:35] <mdiggory> mhwood: correct [16:35] <mdiggory> Which leads to the question of the delivery of a statistics addon for DSpace 1.6 [16:36] <mdiggory> currently the solr stats solution resides int he modules directory with its own release cycle [16:36] <mdiggory> and this is the manner I've proposed the community switch to for creating new features for dspace 1.x and 2.x [16:37] <mdiggory> for instance you will also find dspace-srw and several other webapps/addons among the projects there [16:37] <mdiggory> including the language packs [16:38] <stuartlewis> How does someone make use of these? Check them out, edit a pom, and mvn' it? [16:39] <mdiggory> as a developer, yes, as a user, they would add them as dependencies to their maven pom, just like the way we use existing dependencies [16:39] <tdonohue> i'm mostly worried about whether this is going to be useable immediately by the folks without much sysadmin support...is there something that will work "out-of-the-box" for 1.6? [16:39] <mdiggory> however, with solr and any other webapplication based addons our current model requires the use of amodules/xxxx project to overaly on [16:40] <mdiggory> the question of it working out of the box has to do with if we enable it by default or not [16:40] <tdonohue> ok [16:41] <mdiggory> I think there would be less questions if the prototype were looked at and reviewed by the group [16:41] <bollini> could we release more packages? a dspace1.6 base, a dspace1.6+stats etc.? [16:41] <mdiggory> https://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services/ [16:41] <mhwood> I *think* I have the prototype here, but I was unclear on what bits to get, where from, how arranged, and how to plumb them together for building. [16:42] <mdiggory> bollini: the idea tends to be that we could release a "base" installation within which you can configure those modules you wish to be using [16:43] <mdiggory> The significant change in this prototype is the addition of... [16:43] <mdiggory> https://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services/dspace/modules/solr/ [16:43] <bollini> mdiggory: ok... but a preconfigured "binary" could help [16:43] <mdiggory> for the solr server that runs statistics storage and querying functionality [16:43] <mdiggory> bollini: if dspace had a "binary" this is as close as we get... [16:44] <mdiggory> the dspace-1.6.0-release.zip would contain just the following contents... [16:44] <mdiggory> https://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services/dspace/ [16:44] <stuartlewis> What are the implications of solr in terms of startup scripts, or is it just another webapp to copy to tomcat? [16:44] <mdiggory> and the build would have solr and statistics eventservices preconfigured [16:45] <mdiggory> just another webapp... I wrote initialization scripts within it that creat the appropriate /dspace/solr directory and configuration on startup [16:45] <tdonohue> is the solr webapp just for stats right now? [16:46] <mdiggory> its also deploys its configuration to dspace/config on that initialization as well [16:46] <mdiggory> the solr configuration that is deployed is "multicore" [16:46] <mdiggory> which means that solr can be utilized for more than just stats. [16:46] <tdonohue> right...gotcha...i'm very familiar with solr [16:47] <mhwood> I have a strong dislike of applications that write in their configuration directories, but I can grumble about that later. [16:47] <mdiggory> the solr server would be part of the release no matter if we ustilize UsageEvent or EventService [16:48] <mdiggory> mhwood: that can be altered if it becomes too offensive ;-) [16:48] <stuartlewis> So it sounds like we just need to make a decision and get on with it. [16:48] <mdiggory> pretty much... [16:48] <stuartlewis> Is everyone happy to make a decision now, or do we want to look into the prototypes further? [16:48] <rrodgers> I'd say we need volunteers to download/testdrive Mark's config [16:48] <mdiggory> but I have a criticism about making such decisions in meetings like this [16:49] <kshepherd> +1 to more testing [16:49] <tdonohue> rrodgers ++ it'd be good to get some more eyes on this (though it sounds good, based on marks description) [16:49] <stuartlewis> Time is the issue. Would everyone be happy to test in the next 7 days, and decide at the meeting next week? [16:49] <stuartlewis> Or do we need longer? [16:50] <rrodgers> within 2 weeks? [16:50] <tdonohue> i won't be able to help out in next 7...but then again, i'm swamped for a while [16:50] <bollini> I will have no time to check it before the 1.6 release... [16:50] <mdiggory> There are portions of the stats "presentation" work we are still completing... they are my next topic... [16:50] <mdiggory> but I am very much out of time. [16:50] <tdonohue> mdiggory: do you have a demo site to show off the presentation work? [16:51] <mdiggory> and suggest that it can be tested in parralell to those developments [16:51] <mdiggory> tdonohue: once added, they will show up int he dspace JSPUI and XMLUI as simple tables for this iteration [16:51] <mhwood> Do we just checkout http://scm.dspace.org/svn/repo/dspace/branches/dspace-1.6.x-services and we have all we need? I had a notion that I also needed http://scm.dspace.org/svn/repo/modules/dspace-services/trunk stuck into dspace/modules. [16:51] <kshepherd> mhwood: that's dspace 2.0 services i think [16:52] <mdiggory> mhwood: you shouldn't, hey are delivered by Maven [16:52] <mdiggory> and are in the snapshot dspace maven repo [16:52] <bollini> sorry... I need to leave, I will check the logs tomorrow [16:52] <mdiggory> and would be deployed to the central repo on release [16:52] <stuartlewis> Thanks Andrea. Bye. [16:52] <bollini> bye all [16:52] * bollini (n=chatz...@host142-190-dynamic.17-87-r.retail.telecomitalia.it) Quit ("ChatZilla 0.9.85 [Firefox 3.0.13/2009073022]") [16:53] <mdiggory> I'm afraid I will need to go as well... But it is clear that I need to provide some guidelines for testing the prototype and will do so. [16:53] <mhwood> dir [16:53] <mhwood> Sorry, wrong focus. [16:54] <rrodgers> thanks mdiggory [16:54] <tdonohue> thanks mdiggory! [16:54] <mdiggory> hehe [16:54] <mhwood> mdiggory: yes, please, and thanks! [16:54] <mdiggory> ok... will try to get that out asap... [16:54] <mdiggory> bye all [16:54] <stuartlewis> Thanks Mark. Bye. [16:54] <kshepherd> seeya, cheers [16:54] <mhwood> 'bye [16:54] * mdiggory (n=mdigg...@64.50.88.162.ptr.us.xo.net) Quit () [16:54] <tdonohue> bye Mark [16:54] <stuartlewis> So... back to embargoes, or does anyone want to talk about stats more? [16:55] <tdonohue> not right now...i was wondering whether there's anything for the embargos that will be "out-of-the-box" or not... [16:55] <rrodgers> To answer tdonohue question: embargo always depends on a policy, which we won't define [16:56] <tdonohue> that makes sense...but how do the policies get configured? [16:56] <rrodgers> but, if one's needs are really simple (like putting in an end date), there will be sample code (like Harvard's) that [16:56] <rrodgers> you can use as is. [16:57] <tdonohue> i'm worried a bit on how easy this would be for folks without much sys admin support [16:57] <rrodgers> If one's need are more complex, you write the logic in a java class [16:58] <tdonohue> "complex = java" makes sense...I'd just hope there's something simple that folks without a sys admin can set up for now [16:58] <mhwood> Apparently "simple = somebody else already wrote one" [16:59] <stuartlewis> Can we ship some basic preconfigured options that just uncommenting etc? [16:59] <rrodgers> I debated offering samples with the distribution, and can do, but I'm not convinced there are any cases that really address that many institutional needs [16:59] <rrodgers> stuartlewis: yes we can [16:59] <tdonohue> yea...i'm just trying to think from the point of view of the folks who requested these features from the community-outreach surveys...there's quite a few folks there who don't have java support locally, etc. [17:00] <rrodgers> What I am worried about is this: there are things like language dependencies that are sticky [17:00] <tdonohue> hmmm...true [17:00] <rrodgers> I can give you a "6 months" but how about a "6 monat" etc [17:01] <rrodgers> the point is that policy language tends to be native [17:01] <tdonohue> and i'm assuming the current i18n stuff just won't cut it with this? [17:01] <kshepherd> could we come up with some i18n keys for common date/time/emgargo terms? [17:01] <kshepherd> embargo* [17:02] <rrodgers> kshepherd: in time I think we could, but I think the code needs to be socilaized a bit first [17:03] <rrodgers> also, there were many cases where poliicies don't even involve dates but references to publishers etc [17:04] <stuartlewis> Sounds good anyway. Looking forward to it :) [17:04] <tdonohue> i'm still worried that people will be expecting "out-of-the-box"...i.e. they expect to upgrade to 1.6 and suddenly see an "embargo" step/option in submission process, etc. [17:04] <tdonohue> but, maybe that's just me...i could be wrong [17:04] <kshepherd> i do have to agree that there is very little common ground between various institutions' embargo requirements, even though it has been requested as one broad feature [17:05] <mhwood> Could the specific i18n issues be enumerated, categorized and laid out in an email for study, without a lot of work? [17:05] <stuartlewis> tdonohue: Yes - just a basic one like setting a date during submission or workflow. [17:05] <tdonohue> stuartlewis: yea, definitely nothing complex...very simple [17:05] <rrodgers> stuartlewis: tdonohue I can give you a 'set the date' out of the box - it's just a plugin [17:06] <tdonohue> rrodgers: i think that'd be great [17:06] <rrodgers> In fact Harvard already wrote it [17:06] <rrodgers> All you have to do is in dspace.cfg pick a metadata field to use and its done [17:06] * ksclarke (n=ke...@ip-152010148147.library.appstate.edu) Quit ("Leaving.") [17:06] <tdonohue> ok, then that covers my worries...i don't think i had understood what was written and what wasn't [17:06] <mhwood> That might cover a lot of cases and give some time to study the more complex ones. [17:07] <stuartlewis> An hour is up now. Do we have more to talk about, or shall we wrap it up for today? [17:07] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer)) [17:07] <rrodgers> OK we'll launch with that one [17:07] <tdonohue> sounds great... [17:07] <tdonohue> i think i'm done...i gotta run anyways [17:07] <mhwood> I need to go too. [17:07] <tdonohue> thanks all! [17:07] <kshepherd> cheers, bye all [17:08] <mhwood> Thanks! [17:08] <rrodgers> thanks all [17:08] * rrodgers (n=rrodg...@dhcp-18-111-15-222.dyn.mit.edu) Quit () [17:08] * tdonohue (i=80ae2...@gateway/web/freenode/x-vxiuichdecaqycee) Quit ("Page closed") [17:08] <stuartlewis> Thanks. Bye. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
