Below is the transcript of a committer's meeting held on #dspace at irc.freenode.net at 16:00 GMT on May 13, 2009.
We intend to hold the next meeting on #dspace May 27 at 20:00 GMT. There is no meeting today, May 20, as much of the community is involved in OR2009. 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&ctz=America/New_York Anyone is welcome to attend. Meeting Summary: Discussion of the repository move, future of statistics, and directions of Cocoon (XMLUI). Transcript: (Thanks, Kim) 15:53 -!- stuartlewis [n=stuar...@gendig21.lbr.auckland.ac.nz] has quit [Read error: 110 (Connection timed out)] 16:27 -!- mdiggory [n=mdigg...@64.50.88.162.ptr.us.xo.net] has joined #dspace 17:41 -!- gaurav_hiiii_ [n=chatz...@59.98.136.5] has quit ["ChatZilla 0.9.84 [Firefox 3.0.8/2009032609]"] 18:20 < mdiggory> is there any plan for a commiter meeting today? 18:21 < mhwood> Yes, 1600 ET 18:22 < mdiggory> K 18:22 < mdiggory> good leaves me some time for lunch 19:55 -!- bradmc [n=bra...@129.174.112.5] has quit [] 19:55 -!- Stuart-Lewis [n=7962d...@67-207-133-29.slicehost.net] has joined #dspace 19:56 < Stuart-Lewis> Morning / afternoon / evening all :) 19:56 < kshepherd> morning Stuart-Lewis 19:57 < Stuart-Lewis> Hi Kim. In work yet, or being a slob like me and still at home? 19:58 < kshepherd> home 19:58 < Stuart-Lewis> Sensible! 19:58 < kshepherd> i was up unitil 3am last night 19:58 < kshepherd> so not just sensible... surprised i woke up in time 19:58 < kshepherd> ;) 19:59 -!- tdonohue [n=80ae2...@67-207-133-29.slicehost.net] has joined #dspace 19:59 < mhwood> Thanks for being here so early. 20:00 < Stuart-Lewis> mhwood: it is 8am here, so not too bad. It is the 4am meetings that are a killer! 20:01 -!- bollini [n=chatz...@host232-232-dynamic.17-87-r.retail.telecomitalia.it] has joined #dspace 20:01 < Stuart-Lewis> IIRC Brad is not around for the meeting today. 20:01 < Stuart-Lewis> Suggestions for topics? 20:01 < Stuart-Lewis> 1) An update on where we are with the svn migration? 20:02 < bollini> 2) status of 1.6 working group? 20:02 < Stuart-Lewis> The stats / embargoes / bath edit working groups? 20:03 -!- rrodgers [n=rrodg...@dhcp-18-111-2-16.dyn.mit.edu] has joined #dspace 20:03 < bollini> yes 20:03 < mdiggory> 3.) GSoC coordination 20:04 < mdiggory> rrodgers: you missed the first couple topic ideas... 20:04 < mdiggory> Stuart-Lewis: 1) An update on where we are with the svn migration? 20:04 < mdiggory> [1:02pm] bollini: 2) status of 1.6 working group? 20:04 < mdiggory> [1:02pm] Stuart-Lewis: The stats / embargoes / bath edit wor 20:04 < bollini> 4) event system... again 20:04 < rrodgers> thanks for recap 20:04 < rrodgers> BTW - can someone take responsibility for recording and posting this? I gather Brad cannot today 20:05 < kshepherd> i'm logging 20:05 < mhwood> Sounds like plenty to talk about. I am logging. 20:05 < rrodgers> k thanks 20:05 < mdiggory> sure I can 20:05 < mdiggory> SVN migration, we have two or three subtopics 20:05 < Stuart-Lewis> mdiggory: Do you want to kick of with svn then? 20:06 < mdiggory> a.) with SF now frozen we should clear up what to do with trunk and branches as I proposed in commiters list 20:06 < Stuart-Lewis> a) Maybe leave it there for 3 months and see if it causes a problem? I like the thought of having it preserved on SF for a while. 20:06 < mdiggory> current proposal is to delete the exisitn HEAD revisions for trunk and branches and put in place a readme pointing to scm.dspace.org 20:07 < bollini> +1 for remove *now* putting a notice 20:07 < mdiggory> SF will be there as long as they decide to keep the code up. 20:07 < mdiggory> history will be there, this is just altering the top-most revision to hid trunk nad branches 20:08 < mhwood> So long as they are still accessible somewhere, deleting from SF now emphasizes that new work will not be seen there until release. 20:08 < rrodgers> Is there a fairly clear map from what was there to current scm resources? 20:09 < mdiggory> mhwood: at least from that standpoint that it will not be visible in the SF svn and instead the scm.dspace.org repository 20:09 < mdiggory> rrodgers: everything is 1 to 1, a complete replication 20:09 < rrodgers> cool 20:09 < bollini> what about google sandbox? 20:10 < Stuart-Lewis> So the whole history will be on SF, just there will be a new head revision? Sounds fine to me then. 20:10 < mdiggory> http://scm.dspace.org/svn/repo/dspace = http://dspace.svn.sf.net/svnroot/dspace (minus dspace2) 20:11 < bollini> on OSL we have also the full history 20:11 < mdiggory> I am working on dspace-sandbox ATM, Google does not allow access to the origianl repostiory contents, it will be difficult to retain the commiter specific history 20:11 < mdiggory> svnsync is a tool available to replay the commits to a new repository. I am testing it at this time 20:12 < mdiggory> I'm also researching replicating the repo with git 20:12 < mdiggory> and exporting to svn for merging with the OSL repo 20:12 < mdiggory> but I have to ask, is retaining commit history of dspace-sandbox critical? 20:13 < Stuart-Lewis> I wouldn't say so. It has had far less use. 20:13 < mdiggory> I assume it will just sit there the same as SF 20:13 < mhwood> The one thing I have in there is outdated and useful only for code archaeology. 20:13 < mdiggory> We could just skim the head for all the modules and put them under /modules/ in the OSL repo 20:14 < bollini> I think that we can make just 3-4 major commit for the i18n modules 20:14 < mdiggory> it would be much easier for me to do 20:14 < bollini> just preserve the 1.5, 1.5.1 and 1.5.2 tag for i18n 20:14 < mdiggory> it can be individual projects, or all at once... 20:15 < mdiggory> bollini: they would all be preserved as branches in OSL 20:15 < mdiggory> We would just bring over the whole svn project tags/branches/trunk at once 20:16 < bollini> it's fine for me 20:16 < Stuart-Lewis> Same here. 20:17 < mhwood> No issues here. 20:17 < kshepherd> yep sounds good 20:17 [Users #dspace] 20:17 [ bollini ] [ jrutherford] [ kshepherd] [ mhwood ] [ Stuart-Lewis] 20:17 [ DarthWader] [ krnl_ ] [ mdiggory ] [ rrodgers] [ tdonohue ] 20:17 -!- Irssi: #dspace: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal] 20:17 < rrodgers> Beyond the current sand-box code, do we imagine a similar area in scm? 20:17 < mdiggory> Yes, yes, and yes 20:18 < mdiggory> Initially I'm putting up... https://scm.dspace.org/svn/repo/modules/ 20:18 < mdiggory> for i18n and other projects at dspace-sandbox (and a few floating around) 20:18 < rrodgers> So then we should put some messaging at Googlecode to that effect 20:19 < mdiggory> Rght, we need to see about what is happening with the prototypes there. seek out those individual commiters and determine if they will come to OSL instead 20:20 < Stuart-Lewis> Are there many active projects on there right now? 20:20 < rrodgers> yes, both pro-actively as you suggest, but also a notice that activity is continuing elsewhere for casual visitors 20:21 < mdiggory> c.) post commit hooks are in place and emails are flooding the dspace-changelog nicely. 20:21 < mdiggory> rrodgers: Stuart-Lewis I assume this migration will be an iterative process. 20:22 < mdiggory> I could use some volunteers to alert dspace-sandbox commiters and the community about the changes. Maybe even do some of the admin and migration activities. 20:22 < bollini> we need to configure JIRA to look at the new repo 20:22 < mdiggory> bollini: I pinged Brad on that topic 20:23 < mdiggory> we also need to do something with the Fisheye at Atlasian 20:24 < Stuart-Lewis> mdiggory: Do you want me to draft an email about the svn changes as a follow up to the one I sent about us reorganising the structure? I can run it past you later today. 20:24 < mdiggory> That would be great, we would want it to go out to the community at large and any users on he dspace-sandbox 20:25 < Stuart-Lewis> OK. 20:26 < Stuart-Lewis> Is that SVN all wrapped up for now? Next topic, or more to talk about? 20:26 < mdiggory> much of the dspace-sandbox repo seems to be just i18n, so I am not too concerned with migration. 20:27 < rrodgers> except that i18n is one place where we experimentally model distributed development... 20:28 < mdiggory> it will still be distributed in that it will not be "part" of the dspace directory, but part of modules 20:28 < mdiggory> our responsibility will be to get more commitership on it and involved with its maintenance. 20:28 < Stuart-Lewis> Once youve got the language packs moved, I'll fix up the trunk poms to pull from there instead. 20:29 < mdiggory> possibly even automate releases via continuous integration 20:29 < mdiggory> thanks Stuart 20:30 < mdiggory> I think thats about all on SVN at the moment 20:30 < Stuart-Lewis> Ok. So 2) Update on 1.6 new feature working groups 20:30 < rrodgers> Who first? 20:30 < Stuart-Lewis> You'll have seen my email about the wiki page for batch editing. not much community response yet. 20:31 < Stuart-Lewis> If anyone here has anything to add to it, please do :) 20:31 < rrodgers> MIT has a contribution - a collegue will add to wiki 20:31 < Stuart-Lewis> Cool. 20:31 < Stuart-Lewis> Larry also has a contribution he is working on with Harvard. 20:32 -!- gabriela [n=8e96c...@67-207-133-29.slicehost.net] has joined #dspace 20:32 < Stuart-Lewis> Next update? Stats? 20:33 < mhwood> I still need to get an email out and start stirring up discussion. I've had one private email asking about COUNTER. 20:33 < mdiggory> I somewhat ponder if we should be considering some proof of our "distributed development" model with stats 20:34 < tdonohue> mhwood: don't forget about Minho's work (obviously)...and I have a highly customized version of Rochesters old stats for http://www.ideals.uiuc.edu 20:34 < mdiggory> I.e. Stats becoming a module project as another proof of concept concerning plugins and modularity 20:34 < rrodgers> As for embargoes, I'll also put up a wiki page. I've received a few inquiries. The only current reasonably mature work I'm aware of is Metsger's & @mire/dryad. Any others? 20:35 < mdiggory> Likewise @mire uses some of the UsageEvent work in 1.5 to process events to its statistics products 20:35 < tdonohue> rrodgers: we have embargoes as well..but they are "hackish"...they are based on the Michigan code on the Wiki (it's essentially a temporary withdrawl of an item) 20:36 < mhwood> We're using Rochester stat. code here too. 20:36 < rrodgers> OK thanks, I'll include Michigan's as a reference at least 20:36 < mdiggory> @mire has two Embargo solutions ATM one is dependent on code modifications that allow extended metadata on Bitstreams, the other not 20:37 < Stuart-Lewis> Are there public examploes of minho and rocheter that we can show people to help them give feedback? 20:37 < mdiggory> the other is the Dryad solution 20:37 < tdonohue> mhwood: Ok, just wasn't sure if you had Rochester's stats running in 1.5.x...and we've done some customizations to it so that it will scale a bit better than the initial Rochester code 20:37 < rrodgers> mdiggory: do you mean 3 then? 20:37 < mdiggory> no, just 2 20:38 < rrodgers> OK - the non-extended bitstream md = dryad 20:38 < mdiggory> right 20:38 < tdonohue> Stuart-Lewis: If you look at the IDEALS homepage.....there's a top ten download list we generated with the Rochester stats: http://www.ideals.uiuc.edu/ and stats on each community/collection/item page (at bottom of each) 20:38 < mdiggory> Dryad Embargos Items, our other solution that we havn't yet made public Embargos individual Bitstreams 20:39 < mhwood> tdonohue: maybe we should compare notes and see if some sort of merged version could become a "distributable". I think I need to clear up whether I'm permitted to redistribute. (I don't see why not but I want it nailed down.) 20:39 < mdiggory> note, Dryad Embargos require no database alteration whatsoever 20:39 < tdonohue> mhwood: that makes sense...all my work can be redistributed, and I wouldn't want to lose some of the stability changes we've made (unless you've come up with something better!) 20:40 < mdiggory> and rely on metadata fields 20:40 < bollini> we also use the dryad embargos 20:40 < mhwood> https://scholarworks.iupui.edu/ is 1.5.1 XMLUI with Rochester stat.s. 20:41 < kshepherd> i have a homegrown stats package, it's not 100% mature yet.. http://aut.researchgateway.ac.nz/dstats/ 20:41 < kshepherd> (and it's clear that i suck at css ;)) 20:42 < tdonohue> kshepherd: still looks good...i like that it has various reports you can run 20:42 < mdiggory> This is why I feel it critical that Usage/Statistics be looked at as third party. There are multiple solutions. 20:43 < mdiggory> We want to foster a bit of competition here 20:43 < mhwood> Yup, I don't think we're going to imagine a single Way for everyone. 20:43 < mdiggory> to assist these in evolving 20:43 < tdonohue> mdiggory: Yea, i think i agree...though it'd be nice to provide *something* out-of-the-box (or very easy to add on), with the ability to switch out what that something is... 20:43 < Stuart-Lewis> donohue: +1 20:44 < Stuart-Lewis> People want to know there is something stable and inbuilt that will be maintinedin the long term, and if they want something better, they can take a bit more of a risk with an add-on. 20:44 < Stuart-Lewis> s/donohue/tdonohue (appologies!) 20:44 < mdiggory> Yes, my only concern is that some of these (I assume Minho here) still involve patching and altering the dspace classes directly? 20:45 < Stuart-Lewis> To me Minho might be too complex to built into core, and should be an addon. Is Rochester any simpler? 20:46 < mhwood> Minho has worked to plugin-ize their work but I'm not fully aware of its status. 20:46 < tdonohue> I have Rochester totally separated out from the core (at least in the 1.5.x XMLUI)...the only change is that it has it's own custom "BitstreamReader" which records the stats to the separate Stats DB tables 20:46 < tdonohue> but, beyond that, our Rochester code doesn't touch the core DSpace api 20:47 < mdiggory> @mire's is a XMLUI/JSPUI overlay for links/presentation, Filters/UsageEvents and separate Webapplication for storage 20:48 < mhwood> How do you mean simpler? Simpler to connect to DSpace, simpler to use, less visible.... 20:50 < mdiggory> mhwood: I think you stumped us 20:50 < Stuart-Lewis> simpler = less code changes etc. 20:50 < Stuart-Lewis> And Tim has confirmed it is. 20:51 < Stuart-Lewis> (I assume you were refering back to my comment asking if Rochester was simpler?) 20:51 < mdiggory> At least in the XMLUI case, there should be almost no alteration of existing codebase to attain reasonable UsageStatistics 20:51 < kshepherd> mine's absolutely seperate, even the tables are in a different DB, but it's very clunky... and I need to update it to work with UsageEvent 20:52 < mhwood> There should be no API changes required for Rochester when using the UsageEvent stream. DB tables were always separate. I whipped up an Aspect to salt the results into DRI on the XMLUI side. The JSPUI side is still somewhat invasive. 20:52 < mdiggory> @mires storage is completely separate 20:52 < mdiggory> as well 20:53 < tdonohue> so, it sounds like Rochester's and @mire's and kshepherd's are all "in the running" :) 20:53 < Stuart-Lewis> Are we agreed we need something better as part of the core distribution, or should the choice for stats always be module and done as a 3rd party add-on? 20:54 < Stuart-Lewis> s/module/modula 20:54 < kshepherd> well, i think the UsageEvent plugin is already on the right path 20:54 < mhwood> There could be multiple "adopted" packages, for that matter, if they are all pluggable. 20:54 < kshepherd> if you look at stats as breaking down into logging, reporting, presentation 20:54 < tdonohue> i agree with your point Stuart, that we need *something* in the core distribution....with the ability for technical users to switch it out in favor of a 3rd party add on 20:55 < Stuart-Lewis> So is Rochester looking like the best solution for that? 20:55 < mdiggory> I think we should have the existing stats code in dspace pushed to a modules (accept UsageEvents) as an example of how statistics would be added onto DSpace 20:55 < mhwood> But first we need to work out what kinds of statistics, and their presentations, different users want. Administrators and contributors have different ideas about what it's important to know, I think. 20:55 < mdiggory> then each provider can use that model to provide there solution 20:56 < mhwood> Aha, I had made a note to look at event-izing the existing built-in. 20:56 < mdiggory> switching out statistics should really just be changin the dependencies in your build process 20:56 < mhwood> A hollow voice says, "JSPUI". 20:57 < mdiggory> mhwood: @mire has experience with this from dealing with many cases 20:58 < mhwood> Even the XMLUI side needs theme changes. Maybe XMLUI needs a review w.r.t. modularity. 20:58 < mhwood> Modularity of the Theme stage, I mean! 20:59 < mdiggory> mhwood: modularity of the theme stage is a really good topic 20:59 < mdiggory> If we can utilize Cocoon blocks to deliver our theme resources to the webapplication, then theres no "overlaying" required 21:00 < mhwood> We've reached the 1hr. mark. 21:00 < mdiggory> I.E. theme resources come right along witht he aspects and other services delivered by the block 21:00 < mhwood> I'll have to study that. 21:01 < tdonohue> I think there still needs to be a "default" stats option. I'm of the frame of mind that people need to be able to install DSpace *without* messing with dependencies...otherwise we are just making DSpace more difficult to install for less-technical users 21:01 < mdiggory> both this is a change that needs working on, I almost considered it for the Cocoon 2.2 port, parts of it are in 2.0, I excluded it from 1.5.x out of concern for backward compatability 21:01 < mhwood> I was just figuring out Cocoon when 2.0 set me to learning Spring. I need longer days. 21:02 < mdiggory> mhwood: Cocoon 2.2 is Spring... 21:03 < mdiggory> and not to sacre anyone even more... Cocoon 3.0 is OSGi... 21:03 < mhwood> Agreed that some stat. package should be default, when we know what it should be. 21:03 < Stuart-Lewis> +1 21:04 < mdiggory> I was still thinking the default would probably be what exists in DSpace today, moved out to a module addon 21:05 < mhwood> Yeah, minimum change there. 21:05 < bollini> mmm... and if we make an additional distribution with a plugin module pre-installed? 21:05 < bollini> s/plugin/stats 21:05 [Users #dspace] 21:05 [ bollini ] [ gabriela ] [ krnl_ ] [ mdiggory] [ rrodgers ] [ tdonohue] 21:05 [ DarthWader] [ jrutherford] [ kshepherd] [ mhwood ] [ Stuart-Lewis] 21:05 -!- Irssi: #dspace: Total of 11 nicks [0 ops, 0 halfops, 0 voices, 11 normal] 21:06 < Stuart-Lewis> Buut we know the default now is not good enough for what people want - as a module or not. 21:06 < mdiggory> bollini: I thought it would be installed in the standard distro, just like i18n 21:06 < Stuart-Lewis> We need something better as default. 21:06 < mhwood> It's not what *some* people want. It's management stat.s. Some people want other kinds of stat.s. 21:07 < kshepherd> hmm.. fwiw, my repo admins liek their built-in stats to stay private.. it does report on a few slightly different areas 21:07 < mhwood> This is what I keep coming back to: what does "better" mean to various groups, and how do the meanings cluster? 21:07 < kshepherd> that's another example of where multiple reporting/present modules help 21:07 < kshepherd> presentation* 21:08 < Stuart-Lewis> mhwood: Guess we need to initiate a process to ask the community what they want 21:08 < mhwood> Yes, that's what I'm supposed to be doing. 21:09 < mdiggory> yes, they want administrative stats so they can keep a pulse on the repo 21:10 < mdiggory> and yes those tend to be kept internal 21:10 < kshepherd> i've got another meeting to rush off to now, sorry it's a teleconference so i might still be semi-here 21:10 < mhwood> As kshepherd says, stat.s need further layering. 21:11 < Stuart-Lewis> They also want public item-level stats on the item pages to keep the authors happy. 21:11 < mhwood> Anyway, this discussion should be on the lists, yes? 21:11 < Stuart-Lewis> Yes 21:11 < rrodgers> What are we doing about next week's session - it's in middle of OR? 21:12 < mdiggory> I assume we will be looking for a nice "venue" 21:12 < Stuart-Lewis> !) Not hold it as it will be quiet, or 2) Hold it and encourage people to join in, show them IRC etc? 21:12 < rrodgers> Not sure what to do 21:13 < mhwood> I'd assumed we would skip next week. 21:13 < mdiggory> I think we will all be very distracted and overwhelmed with the Confrenece and recommend not holding 21:13 < Stuart-Lewis> Skipping it is probably the most sensible solution? 21:13 < rrodgers> fine with me - I'm in the same boat 21:14 < tdonohue> makes sense to me as well 21:14 < bollini> ok 21:15 < Stuart-Lewis> OK - looks like we all agree 21:15 < Stuart-Lewis> Can someone update the google calendar? 21:17 < Stuart-Lewis> Got to go now - late for work. Bye! 21:18 < mhwood> Folk are leaving -- time to wrap up? 21:18 < rrodgers> I think so 21:18 < mhwood> "event system" got starved out -- can we take that up first next time? 21:18 < bollini> ok... good night from Italy 21:18 < mdiggory> Oh, I'll toss in one last tidbit 21:18 < mdiggory> the @mire statistics solution runs on solr... 21:19 -!- Stuart-Lewis [n=7962d...@67-207-133-29.slicehost.net] has quit ["CGI:IRC (EOF)"] 21:19 < bollini> bye 21:19 -!- bollini [n=chatz...@host232-232-dynamic.17-87-r.retail.telecomitalia.it] has quit ["ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]"] 21:19 < mdiggory> Till next time. 21:19 < rrodgers> bye all 21:20 < mhwood> 'bye ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
