Below is the transcript of a committer's meeting held on #duraspace at irc.freenode.net at 18:00/19:00 GMT on September 9, 2009.
We intend to hold the next meeting on #duraspace today, September 16 at 20: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: Meeting was brief as we allocated time to polish off the Jira Review. We decided to do Jira reviews in the first 15 minutes of future committer meetings. Embargoes for 1.6 about to be checked in. Discussion of progress on stats, and consideration of providing just the capture code in 1.6, with a UI to follow in 1.6.1. Transcript of committer's mtg, see jira review at http://duraspace.org/irclogs/index.php?date=2009-09-09 : [15:25] <stuartlewis> OK - that is the list complete (woohoo!) that we have on JIRA. [15:25] <bradmc> 3 min break, then comm mtg? Topics of interest for today? [15:25] <tdonohue> not sure if I should bring it up, but there's another Checksum Checker bug I logged today [15:25] <tdonohue> DS-302: Checksum Checker re-processes bitstreams marked "to_be_processed=false" at beginning of month. [15:26] <tdonohue> http://jira.dspace.org/jira/browse/DS-302 [15:26] <bradmc> Topic: Jira review as part of weekly comm meeting? [15:26] <tdonohue> yep, good idea [15:26] <stuartlewis> From next week's dev meeting onwards, we'll have the simpler task of just reviewing recent bugs (although next week might be biggish as we'll have 4 weeks worth of bugs to consider) [15:26] <mhwood> Sounds right. [15:27] <stuartlewis> Topics: Update on stats and embargoes [15:28] <mdiggory> getting better, great effort stuartlewis [15:28] <stuartlewis> bradmc: Do you know when the intern effort will be available to get the JIRA tickets updated? [15:29] <bradmc> stuartlewis: Was speaking with him concurrently. He started yesterday (prepping), and will be continuing tonight. Not sure how far he will get, but should see activity every day starting tonight. [15:30] <stuartlewis> bradmc: Excellent :) [15:32] <rrodgers> I think I'm ready to check in Embargoes - got some last-minute fixes from lcs [15:32] <bradmc> Okay: Comm Mtg: (1) Jira reviews, (2) Stats update, (3) embargo update. [15:32] <stuartlewis> rrodgers: Excellent news - thanks :) [15:32] <bradmc> Jira Reviews: Propose: First 15 minute of weekly comm mtg for Jira reviews. [15:32] <stuartlewis> bradmc: +1 [15:32] <mdiggory> +1 [15:32] <mhwood> +1 [15:32] <rrodgers> +1 [15:33] <bradmc> Okay. We'll come up with some initial rules, revised from Stuarts for the initial reviews. Something about how to handle reopening issues :) [15:33] <bradmc> Shall we go to Embargoes, since rrodgers started? [15:34] <mhwood> OK [15:34] <stuartlewis> ok [15:34] <rrodgers> Can one of the admins to scm.dspace.org check my account? [15:34] <rrodgers> If I had one, I forgot the credentials [15:34] <mdiggory> looking [15:35] <rrodgers> anyway, while mdiggory looking, I propose to commit Embargo framework, and one *out-of-box* [15:35] <stuartlewis> mdiggory: Can you also look at Scott Phillips email while you've got your head in there - I couldn't find a way of correcting it via the UI, might require some SQL foo. [15:35] <rrodgers> implementation for setting fixed dates (as discussed) [15:36] <stuartlewis> rrodgers: +1 [15:36] <mdiggory> rrodgers: no, you do not ahve an account... use the same account name on SF to create your user [15:36] <mhwood> +1 [15:37] <rrodgers> sure or rlrodgers which is JIRA account name.. [15:37] <mdiggory> can he log in? [15:37] <rrodgers> to JIRA? [15:37] <mdiggory> stuartlewis: can scottatm log in to trac? [15:37] <stuartlewis> mdiggory: Yes, think so. [15:37] <scottatm> let me try... [15:38] <scottatm> :) [15:38] <mdiggory> he appears the only one that can change those details of his preferences [15:38] <stuartlewis> But to change email requires an email to be sent to the current addreess, which is not set IIRC? [15:38] <bradmc> Any more thoughts on Embargo, or should we talk about Stats (and Scott's password) [15:38] <mdiggory> grumble grumble grumble... [15:38] * bradmc thinks the password is mtattocs [15:39] <scottatm> yeah, I can login... just not change preferences or my password because it can not validate my email address. [15:39] <mdiggory> silliness... simplest solution, I delete the account and you recreated a new one [15:40] <stuartlewis> Talk about stats now? We all seem in happy agreement for embargoes to get committed. [15:40] <mdiggory> Stats continues to be worked on [15:40] <mdiggory> @mire has extracted the table and listing presentations we use and we are working on folding them into XMLUI and JSPUI [15:41] <stuartlewis> mdiggory: Any guesses at timescales? [15:41] <stuartlewis> 2 weeks would be good if possible [15:41] <mdiggory> I've been reworking some of the solr configuration and deployment. (I assumed you [15:42] <mdiggory> I assumed you'd have a timeframe proposal like that [15:42] <scottatm> mdiggory: Does that mean there will be atleast some type of stats view in DS 1.6? [15:42] <stuartlewis> I think we need all major features in within 2 weeks to make sure we have time for docs, and materials to be ready for DSUG and a RC [15:43] <mdiggory> scottatm It really depends on what we accomplish by the deadline [15:44] <mdiggory> its not @mire statistics presentation, that is not portable into DSpace Foundation licensing ATM [15:44] <stuartlewis> It is only a deadline for a release candidate (or perhaps better to call it an alpha or beta release if it is known to be incomplete) [15:44] <mdiggory> stuartlewis: we will make that kind of deadline, yes [15:45] <stuartlewis> mdiggory: Excellent - thanks :) [15:45] <scottatm> mdiggory: but it will atleast be someway to surface the stats in the interface? [15:45] <mdiggory> scottatm: it will be "exemplary" of how to surface stats into presentations [15:45] <scottatm> okay. [15:46] <stuartlewis> mdiggory: Is there anything you want us to test in the branch yet? [15:47] <mdiggory> still writing up architectural docs and testing docs... hope to deliver drafts to wiki very soon [15:47] <tdonohue> so, what will be "out-of-the-box" in 1.6? Just a stats framework? Or will stats fully work, but just no UI to them yet? [15:47] <mdiggory> branch is testable for installing and testing dspace-services... so it would be good to test building and installing (adding/removing content) [15:48] <mdiggory> will log to default UsageEventLogger based changes using Event Service [15:48] <mdiggory> that is upto all of us to decide tdonohue [15:48] <stuartlewis> Since a lot of people wouldn't upgrade until 1.6.1 anyway, I suppose having just a framework wouldn't be too bad if we can get some sort of reporting into 1.6.1? [15:49] <mdiggory> I can make it a " [15:49] <mdiggory> profile" [15:49] <bradmc> Interesting thought. [15:49] <mdiggory> that gets activated, or it can be there by default [15:50] <mdiggory> if its there by default, then we will bring more under the 1.x branch IMO [15:50] <bradmc> If you don't have it activated, and activate it later, have you lost the opportunity to collect those stats? [15:51] <mdiggory> Yes and No... [15:51] <mhwood> I think there is a need for a gadget to load old observations from logs or something. [15:51] <mdiggory> stats are still logged to files... [15:51] <mdiggory> thats something that is experimental ATM... [15:53] <mdiggory> but some details of stats logging calculations if not calculated immediately [15:53] <bradmc> It would be nice if that future, "1.6.1 reporting upgrade" resulted in magical display of history. [15:53] <bradmc> Which argues for having it on out of the box in 1.6. [15:53] <tdonohue> +1 bradmc [15:53] <stuartlewis> +1 [15:55] <mdiggory> reporting code currently has log file "troller", can be repurposed for indexing log files [15:55] <stuartlewis> Sounds good. [15:56] <bradmc> That's the other solution to the nice-to-have requirement. [15:56] <tdonohue> that's a nice feature [15:56] <mdiggory> yes, anyone interested in experimenting in that area is welcome to join in [15:56] <mdiggory> and should be able to work against the dspace-services-prototype branch [15:57] <bradmc> We are coming to the end of our 30 minute "hour" [15:57] <bradmc> As always, there is no "Off switch" for IRC, so keep going if you wish. [15:58] <tdonohue> so how do we plan advertise the stats for 1.6, if there's no UI immediately? Will most people still see that as "stats", or will they even be aware of it if it's all behind the scenes? [15:58] <mhwood> Topic: communicating scheduling changes. There was some confusion earlier today as to the time of this meeting. [15:58] <mdiggory> tdonohue: we are working on UI presentations. [15:59] <mdiggory> we are providing a simple UI [15:59] <scottatm> mhwood: we're you at one point working on an XMLUI aspect to collect and view stats? [15:59] <mdiggory> I.E. table... [15:59] <tdonohue> ok, i misunderstood then.. I thought you said there were just "examples" being provided [15:59] <scottatm> mhwood: is that something possible to hook up to the @mire/solr collector? [16:00] <mdiggory> I'm saying they will not have "bells and whistles" [16:00] <rrodgers> I have to run - (mdiggory: gentle reminder about scm account) [16:00] <mdiggory> thnx [16:00] <tdonohue> mdiggory: ok, got it...my mistake [16:00] <bradmc> mhwood: my failure. been so long since we changed, I neglected to hit the google calendar. [16:01] <mhwood> We have XMLUI code to detect and summarize viewing of items, based on the Rochester patch. We haven't done the administrative part yet; still using JSPUI for that. [16:01] <mdiggory> mhwood: can you elaborate? [16:01] <mhwood> I need to look at the new Solr backend to see how we can fit onto it. [16:02] * rrodgers (n=rrodg...@dhcp-18-111-15-222.dyn.mit.edu) Quit () [16:02] <tdonohue> mhwood & scottatm: we have XMLUI aspect/themes to surface the stats generated by the Rochester patch as welll in IDEALS: www.ideals.uiuc.edu [16:02] <mdiggory> mhwood: this is what hthe whole "portlets" debate seems to evolve into... [16:02] <mhwood> Elaborate how? [16:03] <mdiggory> Ok... SolrLogger currently facilitates queries against Solr to retrieve stats results... these will be presented in table in Communit, Collection and Item pages. [16:04] <mdiggory> How does the Rochester patch approach exposure? [16:05] <tdonohue> Rochester patch has its own DB tables to log downloads (it only tracks file downloads), and an API to those tables [16:06] <mhwood> For community and collection, there is a little block down in the lower left corner giving month-to-date and since-counting-began totals. I forget how Item looks, but item detail has an added count column for the bitstream table. [16:06] <tdonohue> Rochester patch also allows you to track IP ranges to "ignore", for know spiders...so you can filter them out of your download totals [16:07] <mhwood> That's the bit I never got done in XMLUI. [16:07] <tdonohue> we have that, mhwood... [16:07] <tdonohue> i ported it all to XMLUI locally [16:07] <mdiggory> spider IP's are part of event serialization in SolrLogger [16:08] <mdiggory> not something that user would configure in viewing... part of UsageEvent processing [16:08] <tdonohue> mdiggory: can you filter out IPs after the fact?...or does it just start filtering at the moment that new IP is added? [16:09] * bradmc steps out and will read later. [16:09] <tdonohue> we ran into many cases with the Rochester patch where we neglected to filter out an IP range for a few months, realized it later, and then corrected our download counts [16:09] * stuartlewis better be off - need to get breakfast and get to work. Bye. [16:09] <mdiggory> I suspect the later. [16:10] <mdiggory> thanks, that is something to consider [16:10] <scottatm> I need to head off too, thanks mdiggory for the answers. [16:11] <mdiggory> yep [16:11] * stuartlewis (n=stuar...@121.98.213.132) Quit () [16:12] * scottatm (n=scott...@peat.evans.tamu.edu) Quit () [16:15] <vy_> thanks everyone, got to go, [16:15] <vy_> \quit ------------------------------------------------------------------------------ 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
