Below is the transcript of a committer's meeting held on #duraspace at irc.freenode.net at 20:00 GMT on September 23, 2009. It was scheduled for 16:00, but failed to gain quorum.
We intend to hold the next meeting on #duraspace Wednesday, September 30 at 16:00 GMT. (*) 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 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: No Jira review. A brief proposal (not discussed) to move the meeting time to 18:00 GMT every week. Feedback desired. Discussion of a dspace command shell/launcher/loader to address platform independent scripts. Progress update on the Solr stats integration (it's substantial work). Progress update on authority control patch, leading to discussion of how to handle common javascript fragments. Intention to commit embargoes, itemupdater, and opensearch in next week. Transcript of committer's mtg: mhwood:Topic: script wrappers etc. for commandline tools [08:08am]grahamtriggs:unless I get a standing agreement at work to disappear early for the meetings [08:08am]stuartlewis:Topic: stats update [08:09am]stuartlewis:Topic: authority control update [08:09am]bollini:Topic: make community admin configurable - update [08:09am]grahamtriggs:mhwood: how about scripture wrappers? why bother with all these modern languages when latin will suffice? [08:09am] rrodgers joined the chat room. [08:11am]stuartlewis:Graham wants to ad eundum quo nemo ante iit [08:12am]rrodgers:hey all - my topic is just various 1.6 updates [08:12am]lcs:any fundamentalists want to implement script rapture? [08:12am]mhwood:So I suppose Tcl would be heresy. [08:12am]stuartlewis:Did anyone have a chance to look at http://jira.dspace.org/jira/browse/DS-321 'DSpace command line shell'? [08:13am]stuartlewis:If so, what did you think? [08:13am]rrodgers:yes - seems fine with the possible exception of an lcs issue - return codes [08:14am]stuartlewis:Yes - not tried that yet. But the code executes the class in the same thread, and if the thread kills itself with a System.exit(x) then it should just work. [08:14am]lcs:haven't looked at the code yet but the config looks good, though (a) why not just multiple <class> elements, (b) add syntax to explicitly allow user-specified command args. [08:14am]stuartlewis:a) Wasn't sure if the parser would guarantee the ordering of elements [08:15am]stuartlewis:b) Yes, would be a good extension. Just wanted to try something simple out. [08:15am]lcs:there might be a problem running multiple commands when main uses System.exit. [08:16am]stuartlewis:Good point - but if one exists, presumably that is because there is a problem, so you might not want the rest of the commands to run? [08:16am]lcs:xml parsers are supposed to preserve ordering, fwiw. [08:16am]stuartlewis:Having them numbered also helps to pair them up with their arguments [08:17am]lcs:arguments ought to be a child element, then [08:17am]stuartlewis:Good point [08:17am]lcs:most main() [08:17am]lcs:(oops) most main()'s call exit(0) on successful completion.. [08:18am]grahamtriggs:what about re-using ant, and defining the processes as forked tasks? http://marc.info/?l=ant-user&m=102264135822957&w=2 [08:18am]stuartlewis:I've tested the compound commands, and they execute sequentially OK. [08:18am]stuartlewis:grahamtriggs: Richard Jones had problems with that: http://chronicles-of-richard.blogspot.com/2007/03/crawling-like-ants.html [08:19am]stuartlewis:Not sure if they were forked though. [08:19am]rrodgers:also small name quibble - to me a shell is interactive - how about launcher, loader? [08:21am]stuartlewis:launcher maybe good (it isn't 'loading' anything) [08:21am]stuartlewis:OK - so there are some nomenclature issues, some config refinement issues, and some testing to be done. But other than that, is everyone happy with the approach, or is there a different better approach? [08:21am]rrodgers:not a big deal - shell is economically short [08:22am]mhwood:I like not having to look up those long class names. [08:22am]stuartlewis:For 1.6 at least, we can keep the scripts, and make it an option for use that people can try out? [08:22am]rrodgers:I'd say as long as we leave existing stuff (so we don't break crons, etc) [08:23am]mhwood:Does this satisfy the people who dislike distributing platform-specific scripts? (Are any of them here?) [08:24am]stuartlewis:Ok - so unless anyone has a problem with it, I'll try and find some time at the weekend (as well as moving house) to make the requested changes (name / config file) [08:24am]stuartlewis:mhwood: I hope it does. [08:24am]rrodgers:Your solution is so lightweight, I see no reason not to include it [08:25am]stuartlewis:Cool - glad everyone is happy. Next topic? [08:25am]bollini:stats update? [08:26am]stuartlewis:mdiggory: You around? [08:26am]mdiggory:ping [08:27am]mdiggory:looks like I have some catching up [08:27am]stuartlewis:mdiggory: Hi! We were just hoping for a quick update on your stats work. [08:28am]mdiggory:I suppose you are... [08:29am]mdiggory:rather entrenched in that atm [08:29am]mdiggory:Still porting presentation into 1.6.x [08:29am]mdiggory:and testing solr + service deployment [08:30am]stuartlewis:Is there anything any of us can be doing to help out? [08:30am]mdiggory:of course... the timeframe I suggested last week is turning out to be optimistic [08:31am]mdiggory:well, we have grahamtriggs here today, we never formally clarified the usage of dspace-services in 1.6 with you [08:31am]grahamtriggs:otherwise, is there any way to shortcut it - only put the barest bones of presentation in there (ie. a download count on an item), with the rest of the presentation to follow in a second RC, or .1 release? [08:32am]mdiggory:grahamtriggs: yea... it will be bare bones... have we established a formal cutoff date for the rc? [08:32am]stuartlewis:Ideally end of the month [08:32am]stuartlewis:(1 week away) [08:32am]stuartlewis:But if we can't hit that, we hit that. So don't bust a gut over it. [08:33am]stuartlewis:But if we can't hit that, we can't hit that. So don't bust a gut over it. [08:34am]mdiggory:much more is going on that stats/services for us ATM. delay is more resources and time than strategy / implementation problems [08:34am]stuartlewis:Does that sound OK for a timescale, or not long enough? [08:34am]grahamtriggs:mdiggory: dspace-services - is there anything to clarify? My only concerns with what might be in 1.6 is if anything is pushed up into the app server layer, or there are separate processes to be run. [08:34am]mdiggory:grahamtriggs: for statistics we run a solr war... [08:35am]mdiggory:and unlike lucene in DSpace, "there can be only one" [08:35am]mdiggory:unless you do a clustering strategy with solr [08:35am]mdiggory:which uses rsync to replicate slaves from a master [08:36am]mdiggory:but thats over the top... [08:36am]grahamtriggs:mdiggory: I'm thinking I can embed that solr in the main application, and cluster (we use a cluster file system) [08:36am]mdiggory:you can run solr wherever you want and point at it [08:36am]mdiggory:I'm not sure if it will work the same way you could do that with DSpace/lucene [08:37am]mdiggory:solr likes to have but one process operating on the directory at a time (theres a bit of in memory caching going on there) [08:37am]grahamtriggs:what I've read so far today suggests I could, but that's in the realms of theory [08:37am]mdiggory:facet warming etc) [08:38am]mdiggory:Ok, well that would be an interesting and valuable analysis to verify [08:38am]stuartlewis:lcs: bollini: Could you give us an update on authority control? Is it something that will be finished in time and stable enough for 1.6? [08:38am]lcs:Got the basics working on XMLUI and JSPUI; choice control, lookup-popup, autocomplete, on Firefox and Safari. Still have to investigate MSIE issues. [08:38am]lcs:Also have an irresistable improvement (thanks to bollini) to add, and wiki doc update, but expect to be done by next week. [08:39am]bollini:anyway it looks pretty stable [08:39am]bollini:we could include in 1.6 [08:39am]lcs:the authority part and data model is stable. the UI may need some shaking out. [08:40am]stuartlewis:Presumably you'd like to see it in 1.6, rather than put off until 1.7 etc? [08:40am]stuartlewis:lcs: Is it used in DASH? [08:40am]lcs:yes, i want to get it into 1.6. [08:40am]lcs:we're using an early version in production in DASH - mostly what i first checked in. [08:40am]stuartlewis:I'll try and find time to have a play with it later today. Would anyone have a problem with it going into 1.6? [08:40am]stuartlewis:It sounds a great addition. [08:40am]rrodgers:nope [08:41am]mhwood:I think folks here will be pleased. [08:41am]mdiggory:the sooner changes get into 1.6 the sooner we can battle through integration issues [08:41am]stuartlewis:True. [08:41am]stuartlewis:Should we just get it in there now then? [08:42am]stuartlewis:And then do the further work in trunk rather than the brach? [08:42am]mdiggory:always good to fly by the seat of ones pants... [08:42am]rrodgers:wait what are we talking about? [08:42am]lcs:i have one big change left to make (adding collection context to the chioce plugin) and then it would be mostly ready. [08:43am]stuartlewis:rrodgers: Authority control? [08:43am]lcs:i was considering doing the merge in the sandbox first, though. [08:43am]rrodgers:ok, I hoped so [08:43am]stuartlewis:lcs: Sounds sensible. [08:43am]bollini:BTW: it should also solve the duplication issues in browse when the same metadata (case insensitive) is used twice or more times [08:43am]mdiggory:true... I want to understand how much is "addon" and how much is "core" [08:44am]lcs:it's really just a framework added to core. all the actual choice stuff is added on. [08:44am]mdiggory:havn't been watching the commits atm, but see them in the changelog [08:44am]mhwood:If the concept is not controversial, and the implementation is stable enough that there is little chance of having to pull it out again, it's probably time to merge. [08:45am]bollini:the main change to the core is the addition of a new field/column to the metadatavalue [08:45am]lcs:ok, it'll take a couple more days for the "implementation stable" part. [08:45am]lcs:there are also some simple API changes to support the authority and confidence values for each metadata value. [08:46am]mdiggory:lcs: are there significant database changes? [08:46am]lcs:added two columns to the metadatavalue table. [08:46am]bollini:the api changes are mostly (all?) backward compatible [08:46am]lcs:no conversion is needed since the default values are OK. [08:47am]mdiggory:ok [08:48am]lcs:so while we are on this, i have a pile of Javascript that is common between the JSPUI and XMLUI.. wanted to put it in one place and overlay it. [08:48am]bollini:I have had only issues if you define a metadata as "authority control required" and you have invalid data already in place [08:48am]lcs:what is the best way to do this in the maven structure -- add a "webapp" subdir to dspace-api, or create a new project for it? [08:49am]bollini:new project, we can't exclude that in the next future we could have a 3rd UI that don't need this stuff [08:51am]mdiggory:hmm... [08:52am]lcs:i was also tempted to put it in a new subproject under dspace-xmlui, and overlay that on both the xmlui and jspui projects.. but this is a job for a maven maven [08:52am]mdiggory:I do not want us to go down the overlay road too often for smaller cases such as common resources [08:53am]grahamtriggs:can we use the unpack dependency here? [08:53am]lcs:if there's a better way to share common resources in webapps I'll be happy to do that. i just don't want the same code in two places. [08:53am]mdiggory:I would just replicate the resources in xmlui-webapp and jspui-webapp [08:54am]lcs:some of it is my code, which will be subject to updates, and the rest is a patched version of scriptaculous. copies _will_ drift. [08:55am]mdiggory:well, with qualification here....is the pile of javascript referenced in dspace-xmlui-webapp and dspace-jspui-webapp directly or are you doing another maven project for those additions to the codebase... [08:56am]lcs:right now it's directly in the webapp, and it needs to end up in the WAR, but i'm amenable to a separate project for the shared JS code. [08:57am]mdiggory:I'm concerned about setting a precident [08:57am]rrodgers:Sorry, but I've got to run soon - are we done with committer agenda? [08:57am]bollini:a little community admin update [08:57am]mdiggory:I'd just replicate it in both projects and leave a README to keep both uptodate if you start making changes [08:58am]stuartlewis:bollini: Yes - that would be good. [08:58am]bollini:ok, I have completed the api changes and the jspui stuff [08:58am]mdiggory:If we start to get much more replication than this... then revisit the common project strategy [08:59am]bollini:if you have read my last email on the devel list, I have choice the 2nd option - use deferrable strategy with few foreign key constraints [08:59am]lcs:mdiggory: i really don't want copies, nobody looks at READMEs.. but, later. [09:00am]bollini:the api is full aware of the "authorize system configuration" so the xmlui is already in place but we want hide inappropriate buttons [09:00am]mdiggory:I'm concerned about overlaying being used for anything other than end user customization in the modules dir [09:00am]mdiggory:it is an expensive part of the build process [09:01am]stuartlewis:bollini: Is that something you can get done in time for 1.6? [09:01am]mdiggory:and IDE tools are not so good at coping with overlays... [09:01am]bollini:mdiggory: lcs: we can try to keep two separate copies of the js and re-evaluate this decision if it is too expensive [09:02am]bollini:stuartlewis: It will be ready for 1.6 [09:02am]bollini:I will post a first patch (api + jspui) before the end of the week [09:03am]stuartlewis:Excellent [09:03am]stuartlewis:1.6 keeps getting better and better. There will be a lot of new big features in it. [09:03am]lcs:is anyone doing the xmlui work on that, or did i just volunteer? [09:03am]rrodgers:Unless there are objections, in addition to Embargo (checked in), I want to commit ItemUpdater, and OpenSearch within the week [09:03am]bollini:if you all agree I would commit the api stuff as soon as possible so to have enougth time to test it in an integrate enviroments [09:04am]stuartlewis:rrodgers: +1 [09:04am]mhwood:rrodgers, bollini: no objections here. [09:05am]bollini:OpenSearch +1 ItemUpdater 0 I don't know what it is [09:05am]stuartlewis:ItemUpdater is a command line tool to bulk update items [09:05am]rrodgers:bollini: It is a companion to ItemImport and Export - where you can update metdata fields [09:06am]rrodgers:no api or schema changes [09:07am]bollini:nice [09:07am]lcs:++(rrodgers) [09:07am]stuartlewis:Any other business before we close the meeting? [09:08am]rrodgers:OK - thanks all - must go [09:09am] rrodgers left the chat room. [09:09am]grahamtriggs:lcs: increment rrodgers? [09:09am]mhwood:Me too. Thanks all! [09:09am]lcs:grahamtriggs: +1 gets boring ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
