Timestamps are in GMT/BST.
[3:47] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 54 (Connection reset by peer))
[3:47] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[3:47] * mdiggory_ is now known as mdiggory
[3:48] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 54 (Connection reset by peer))
[3:48] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[3:48] * mdiggory_ is now known as mdiggory
[4:05] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:05] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:05] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:05] [freenode-connect VERSION]
[4:49] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 54 (Connection reset by peer))
[4:49] * mdiggory_ (n=mdiggory@76.176.188.83) has joined #duraspace
[4:49] * mdiggory_ is now known as mdiggory
[5:51] * awoods (n=awoods@pool-71-178-169-27.washdc.fios.verizon.net) has joined #duraspace
[6:50] * mdiggory (n=mdiggory@76.176.188.83) Quit (Read error: 131 (Connection reset by peer))
[6:50] * mdiggory_ (n=mdiggory@76.176.188.83) has joined #duraspace
[6:50] * mdiggory_ is now known as mdiggory
[6:52] * mdiggory (n=mdiggory@76.176.188.83) Quit (Client Quit)
[8:12] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:12] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[9:13] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[9:13] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[9:37] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Remote closed the connection)
[9:38] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[10:55] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:12] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 113 (No route to host))
[11:12] * bradmc_ is now known as bradmc
[12:01] * lcs (n=chatzill@72.93.176.242) has joined #duraspace
[12:09] * lcs (n=chatzill@72.93.176.242) has left #duraspace
[12:09] * rrodgers (n=rrodgers@dhcp-18-111-24-120.dyn.mit.edu) has joined #duraspace
[12:11] <rrodgers> hey all - there appears to be a discrepancy in weekly committer IRC time - bradmc last email suggested now, google calendar 4:00 pm EST
[12:12] <bradmc> Did I suggest now? That's a mistake ...
[12:12] <bradmc> Ah, <askdjhas> I did mistype.
[12:13] <rrodgers> OK, fine, no problem. I won't make much of the 4 mtg, but will try to briefly report then
[12:14] <rrodgers> bradmc: can I attend the duracloud webinar?
[12:14] <bradmc> Sure. It's open to the public.
[12:15] <rrodgers> cool see you there/then
[12:15] * rrodgers (n=rrodgers@dhcp-18-111-24-120.dyn.mit.edu) Quit ()
[12:16] <bradmc> Registration from the link in http://expertvoices.nsdl.org/duraspace/2009/09/30/duraspace-webinar-wednesday-sept-30/
[12:41] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[14:04] * bollini (n=chatzill@host113-233-dynamic.11-87-r.retail.telecomitalia.it) has joined #duraspace
[14:05] <bollini> hi all, is there the committer meeting?
[14:06] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:08] <bradmc> bollini: meeting in two hours at 20:00. (We don't seem to have had a conversation confirming the proposal to move to 18:00 all the time).
[14:08] <bollini> ok, it's fine for me
[14:08] <bollini> see you later
[14:15] <bradmc> For Jira issues review today, looks like 14 new issues, see this query: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10030
[14:23] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (lindbohm.freenode.net irc.freenode.net)
[14:37] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[14:42] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:45] * bollini (n=chatzill@host113-233-dynamic.11-87-r.retail.telecomitalia.it) Quit ("ChatZilla 0.9.85 [Firefox 3.0.14/2009082707]")
[15:21] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[15:47] * ysu_jat (n=jeffreyt@maag127.maag.ysu.edu) has joined #duraspace
[15:57] <bradmc> For Jira issues review today, looks like 14 new issues, see this query: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10030 Does someone want to volunteer to either seed them in, or timekeep and summarize?
[15:59] <kshepherd> sure, i'll paste em in again
[16:00] <bradmc> Okay, start from oldest (lowest number), please. Thanks, Kim.
[16:00] <bradmc> Hi folks, we'll wait until about 5 after, then start the Jira review for 15 minutes and see how far we get. If you have discussion topics, please start thinking about them.
[16:01] <bradmc> And toss them out.
[16:01] <stuartlewis> bradmc: Not sure if you saw our chatting yesterday, but it looks like JIRA email is a little poorly right now. No emails for a week or so - all stuck in the JIRA email queue (no reason given in the UI why this is though)
[16:02] * rrodgers (n=rrodgers@dhcp-18-111-24-120.dyn.mit.edu) has joined #duraspace
[16:02] <stuartlewis> Topic: Stats update
[16:02] <bradmc> No, I missed that, I'll go check on it, thanks!
[16:02] <stuartlewis> Topic: NYU security code (session invalidation / XSS at DB INSERT level)
[16:03] <stuartlewis> Topic: Authority controll
[16:03] <stuartlewis> control*
[16:03] <rrodgers> Can I jump in very quickly, since I can't stay?
[16:03] * bollini (n=chatzill@host113-233-dynamic.11-87-r.retail.telecomitalia.it) has joined #duraspace
[16:04] <stuartlewis> Yes
[16:04] <rrodgers> Just a quick update/request on my check-ins, and a question for discussion
[16:05] <rrodgers> I've got eveything in (Embargo, ItemUpdate, OpenSearch) and for gardiners, there is some doc in the JIRA issue
[16:06] <rrodgers> Also, I have a request to do put some metatags for benefit of GoogleScholar, but don't want to hold up 1.6
[16:06] <rrodgers> Are we still freezing around now?
[16:07] <stuartlewis> Ideally we would, but we're still missing stats / authority control.
[16:07] <stuartlewis> What is your timeframe for getting metatags completed?
[16:07] <rrodgers> (at least for major features, not bug fixes)
[16:07] <rrodgers> I'd say a week or so
[16:08] <kshepherd> ok, it's 5 past, i'll start pasting the JIRA review items?
[16:08] * tdonohue (i=80ae241d@gateway/web/freenode/x-fhaeegaplbvseuby) has joined #duraspace
[16:08] <bradmc> Topic: Freeze date, hard / soft?
[16:08] <ysu_jat> rrodgers: Have you flagged Jira for me to gather docs?
[16:08] <bradmc> kshepherd: as soon as rrodgers finishes.
[16:08] <rrodgers> ysu_jat: no, but stuartlewis can give you numbers
[16:08] <ysu_jat> okay..that will work.
[16:09] <ysu_jat> I'm not long on here..leaving at 20:30
[16:09] <stuartlewis> rrodgers: Is it a big change, or a small safe change? (i.e. could it be safely squeezed in after a code freeze?)
[16:09] <bollini> ysu_jat: I have assigned to you the DS-270
[16:09] <rrodgers> Just record thoughts, and I'll read transcript later Sorry for the interruption
[16:09] <bradmc> kshepherd: Go, we'll end at 20:25.
[16:09] <stuartlewis> rrodgers: If you can assign the relevant JIRA issues to Jeff, that might be easiest?
[16:09] <kshepherd> [DS-300] - DescribeStep in configurable submission is not picking up metadata values from the Item Template - http://jira.dspace.org/jira/browse/DS-300
[16:09] <rrodgers> stuartlewis: will do
[16:10] <rrodgers> bye all
[16:10] * rrodgers (n=rrodgers@dhcp-18-111-24-120.dyn.mit.edu) Quit ()
[16:10] <mhwood> 0
[16:10] <bollini> kshepherd: the patch is missed
[16:10] <stuartlewis> -1 no patch (although 'would be nice to fix')
[16:10] <kshepherd> it appears so..
[16:10] <lcs_> 0
[16:11] <bradmc> DS-300: -1. Mark won't fix with request for patch? Keep for later?
[16:11] <kshepherd> -1
[16:11] <grahamtriggs> request patch from Bill, otherwise leave for next release?
[16:11] <bradmc> DS-300: -2: Request patch from Bill, then assign to future release.
[16:11] <kshepherd> grahamtriggs: that sounds the best idea, yeah
[16:11] <kshepherd> [DS-301] - Migrate Item Recommendation functionality to XMLUI - http://jira.dspace.org/jira/browse/DS-301
[16:12] <stuartlewis> Same as 300 - request patch / close
[16:12] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[16:12] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:12] <kshepherd> oops, brad's fallen off
[16:12] <bollini> mmm... next release don't close is a parity issue
[16:12] <mhwood> -1 no patch
[16:12] <bradmc> I'm here.
[16:12] <kshepherd> -1 no patch
[16:13] <lcs_> -1 (would be 0 if patch)
[16:13] <grahamtriggs> Sounds like patch for 301 might be a longer time coming
[16:13] <stuartlewis> Is JIRA the best place for 'feature requests'?
[16:13] <bradmc> DS-301: (think) -3, no patch, mark for post 1.6 (as a feature request).
[16:13] <mhwood> Should be done though
[16:13] <stuartlewis> It might be the best palce, but they are hard to manage, and clog up the working of active patches.
[16:13] <bradmc> stuartlewis: Yes, if they're categorized as such.
[16:13] <mhwood> Where else would feature requests go?
[16:13] <kshepherd> [DS-302] - Checksum Checker re-processes bitstreams marked "to_be_processed=false" at beginning of month. - http://jira.dspace.org/jira/browse/DS-302
[16:13] <grahamtriggs> or... (hang on, goes to find reference)
[16:13] <bradmc> We'll need to figure out how to handle them vis-a-vis reviews.
[16:14] <stuartlewis> 302: Leave open - looks like Tim is working on this one, but out of scope for 1.6
[16:14] <grahamtriggs> re: feature requests - one of these maybe? http://uservoice.com/
[16:14] <bradmc> DS-302: Stays open for now.
[16:15] <stuartlewis> grahamtriggs: Yeah - good idea, but perhaps in rounds, once for each release?
[16:15] <kshepherd> [DS-304] - XMLUI's METS generator ignores authorization - http://jira.dspace.org/jira/browse/DS-304
[16:15] <stuartlewis> 304: Leave open for discussion post 1.6
[16:16] <kshepherd> yeah -1 leave open for later
[16:16] <lcs_> might be addressed by ds-288 (metadata field hiding).. isn't item metadata, as a whole, still public?
[16:16] <mhwood> -1 keep for post 1.6
[16:16] <bradmc> DS-304: (2) Assign to post-1.6.
[16:16] <stuartlewis> lcs_: I think some people would like to lock it down completely sometimes.
[16:16] <grahamtriggs> is that url used internally for retrieving metadata for the ui?
[16:16] <kshepherd> [DS-305] - Kubrick browser-specific CSS does not work consistently - http://jira.dspace.org/jira/browse/DS-305
[16:17] <kshepherd> grahamtriggs: and externally to just get METS XML
[16:17] <kshepherd> grahamtriggs: the example links in teh comments work
[16:17] <stuartlewis> 305: Leave open for later?
[16:17] <mhwood> -1 no patch, leave open
[16:17] <lcs_> -1 no patch
[16:17] <bradmc> DS-305: -2, note no patch, assign to post-1.6
[16:18] <kshepherd> 0
[16:18] <grahamtriggs> kshepherd: which means fixing it could have implications for normal UI display (ie. the access that happens within an authorized visit, may not pass authorization through the internal call)
[16:18] <kshepherd> grahamtriggs: i don't know of anything that uses it, but it's working looking into
[16:18] <bradmc> grahamtriggs, can you add note into DS-304?
[16:18] <kshepherd> grahamtriggs: it's not the same as the DIM that the XMLUI uses
[16:18] <kshepherd> i'm fairly sure it was there to offer machine-readable metadata to external users
[16:19] <kshepherd> [DS-311] - DSQuery should use the Query hierarchy to create the Query object instead of relying onto QueryParser - http://jira.dspace.org/jira/browse/DS-311
[16:19] <lcs_> kshepherd: i believe that is where XMLUI gets item DIM
[16:19] <mdiggory> Last time I suggested this could be managed in the sitemap with the authorizedHandle selector
[16:19] <kshepherd> mm
[16:19] <stuartlewis> 311: Ask for patch - sounds like Flavio might have one.
[16:20] <bradmc> DS-311: Request patch, them assign post-1.6.
[16:20] <mhwood> -1 no patch, keep
[16:20] <mdiggory> Yes, all UI calls to /metadata/ were origininall meant to be internal... OpenSearch appears to change that
[16:20] <kshepherd> mdiggory: oh
[16:20] <kshepherd> did not realise that..
[16:20] <kshepherd> [DS-313] - Patch to add a new AddBitstreamToItem command-line tool and fix up ItemImport a bit - http://jira.dspace.org/jira/browse/DS-313
[16:21] <mhwood> 0
[16:21] <bollini> it is already possible with the itemupdater from richard, right?
[16:21] <mdiggory> kshepherd I think it was left open as a convenience for developers
[16:21] <stuartlewis> Need to ask author to compare functionality to rrodgers new patch that can do similar.
[16:21] <lcs_> isn't itemupdater just for DC metadata?
[16:22] <stuartlewis> lcs_: Can do bitstreams to IIRC
[16:22] <bradmc> DS-313: Add note to have author consider DS-?? from rrodgers.
[16:22] <mdiggory> DS-311 agree they should provide patch
[16:23] <stuartlewis> DS323 is the one to compare against (item update)
[16:23] * bradmc stops looking.
[16:23] <kshepherd> so that's a 0 for ds-313?
[16:23] <bradmc> DS-313: 0 add note to have author consider DS-323.
[16:23] <kshepherd> [DS-314] - Patch to JSPUI: exclude from wildcard fields values which are displayed in specific fields elsewhere on the page - http://jira.dspace.org/jira/browse/DS-314
[16:24] <bradmc> Last one today.
[16:24] <mhwood> 0, I think this needs discussion -- is anybody relying on the current behavior?
[16:24] <ysu_jat> Has this patch be test?
[16:24] <stuartlewis> 314: I'd attack this one differently, and allow a csv of allowed md fields in the config rather than later scanning for duplicates to remove.
[16:25] <kshepherd> 0, can't tell whether this is desired behaviour from other users as well, or just this user
[16:25] <stuartlewis> So from me, -1
[16:25] <kshepherd> agree it'd be nice to make it more configurable
[16:25] <ysu_jat> 0 here
[16:25] <ysu_jat> I think its a configuration issue
[16:25] <grahamtriggs> it sounds useful - but has further implications (ie. should similar logic apply in browse or search configuration?)
[16:25] <bradmc> DS-314: -1, committers to add commentary in notes fields.
[16:25] <bollini> +1
[16:25] <bradmc> DS-314: 0
[16:25] <bollini> ;-)
[16:26] <bradmc> Shall we move along to the meeting?
[16:26] <stuartlewis> I know we said we'd stop here, but can we do 321?
[16:26] <stuartlewis> http://jira.dspace.org/jira/browse/DS-321
[16:26] <bradmc> Sure. Go ahead:
[16:26] <stuartlewis> DSpace command launcher
[16:26] <mhwood> +1
[16:26] <ysu_jat> +1
[16:26] <bollini> 0
[16:26] <lcs_> +1
[16:26] <bradmc> +1 :)
[16:26] <stuartlewis> What do people think of this idea? For 1.6 it need not replace the bin scripts, but will keep the windows users happy.
[16:26] <ysu_jat> Is this easily updatable?
[16:27] <stuartlewis> Yes - update an xml file with new commands
[16:27] <stuartlewis> <command>
[16:27] <stuartlewis> <name>itemcounter</name>
[16:27] <stuartlewis> <description>Update the item strength counts in the user interface</description>
[16:27] <stuartlewis> <step>
[16:27] <stuartlewis> <class>org.dspace.browse.ItemCounter</class>
[16:27] <stuartlewis> <passargs>false</passargs>
[16:27] <ysu_jat> Well, it makes the neophyte unix user happy too.
[16:27] <stuartlewis> </step>
[16:27] <mhwood> Yes, keep scripts for now but schedule them out.
[16:27] <stuartlewis> </command>
[16:27] <bradmc> DS-321: +4, progress for 1.6.
[16:27] <stuartlewis> Ok - will commit today. Thanks.
[16:27] <ysu_jat> <==got to run. See you later all.
[16:27] <bradmc> Thanks, Jeffrey.
[16:27] * ysu_jat (n=jeffreyt@maag127.maag.ysu.edu) Quit ("Leaving")
[16:27] <stuartlewis> Thanks Jeff. Bye.
[16:28] <bradmc> Topics: NYU Security patches, Stats update, Authority Control, Freeze date(s) for 1.6.
[16:29] <stuartlewis> Next topic: XSS / session patches from NYU?
[16:29] <mdiggory> First of several commits to trunk for dspace services / stats is coming this afternoon
[16:29] <stuartlewis> Have you all had a chance to look at it?
[16:29] <mdiggory> oh... yea go ahead
[16:29] <stuartlewis> The session stuff for JSPUI looks fine, sensible, and a no-brainer. Are you all happy with that to get committed?
[16:29] <lcs_> i took a peek; session stuff looks reasonable, although we already have a check by IP address for ession hijacking
[16:29] <bollini> yes, it should solve also the shib issues
[16:30] <stuartlewis> Anyone unhappy if I commit it today? (will satisfy automated penetration test suites)
[16:30] <stuartlewis> OK - will commit it.
[16:30] <stuartlewis> Next up: The XSS code.
[16:31] <stuartlewis> Has anyone had a look at it?
[16:31] <stuartlewis> It seems to pass the bound parameters to all DB IONSERTS via a configurable OWASP filter.
[16:31] <stuartlewis> INSERTS*
[16:32] <stuartlewis> SOunds sensible, but a small performance hit, and not sure if there are any legitimate INSERTS it might corrupt?
[16:32] <bollini> it could broke the collection metadata where html is allowed
[16:33] <stuartlewis> Is there anyone that has a few hours who could give it some testing, and get it mavenized? (there is a new jar file or two IIRC)
[16:33] <mhwood> Sorry, where is this discussed? I can't find it.
[16:33] <stuartlewis> mhwood: dsapce-commit
[16:33] <mdiggory> dspace-commit
[16:33] <kshepherd> fire alarm
[16:33] <kshepherd> brb
[16:33] <kshepherd> (i hope)
[16:34] <mdiggory> I think it need further review
[16:34] <stuartlewis> If we run out of time, XSS could go in a 1.6.1 as there are no db schema changes.
[16:34] <lcs_> if someone sets up a publically-accessible test instance with it, that would let other folks help beat on it.
[16:35] <mdiggory> that could be part of testathon
[16:35] <bradmc> Would we consider making it optional in 1.6?
[16:35] <stuartlewis> Is can be turned on/off in dspace.cfg
[16:35] <stuartlewis> So could be off by default
[16:35] <mdiggory> will need to evaluate dependencies for maven
[16:36] <bradmc> Yes, we need to see clean maven before it goes in, I think. But assuming that is okay, strikes me as a direction to move in.
[16:36] <stuartlewis> htmlparser.jar + antispamy-bin.1.3.jar
[16:37] <stuartlewis> And has a configurable filter in antisamy.xml
[16:37] <mdiggory> yea, but need to review licensing...
[16:37] <lcs_> there ought to be a plan to keep up to date on new releases of these things too
[16:37] <mdiggory> antisamy.xml looks like alot of things could create unpredicatable effects.
[16:38] <mdiggory> but worth of testing
[16:38] <bradmc> I'm worried about a chicken-and-egg problem in finding all the unanticipated side effects, so I'd like to get it in a position to be tested lots of places.
[16:38] <mdiggory> put it in... then take it out if theres issues
[16:38] <stuartlewis> +1
[16:38] <bradmc> Bad would be to wait, release in in a 1.6.1, then force ourselves to a 1.6.2
[16:38] <bradmc> mdiggory: +1
[16:39] <lcs_> +1 with mdiggory's reservation
[16:39] <mdiggory> but.. let me look at the licensing and availability of the jars
[16:39] <stuartlewis> As a side note - I'm creating a 1.6 LiveCD (almost finished) for testathon / DSUG etc.
[16:39] <stuartlewis> Ok - can we leave it with you Mark?
[16:39] <mdiggory> [sigh]
[16:39] <stuartlewis> to get commited / mavenized etc?
[16:40] <stuartlewis> Or would prefer help?
[16:40] <stuartlewis> Or would you prefer help?
[16:40] <mdiggory> ... ouch... stop twisting my arm ;-)
[16:40] <bradmc> Like Mark didn't have enough to do ... such as stats ... speaking of which, Mark?
[16:40] <mdiggory> I've got some commits streaming in today and the rest of the week
[16:41] <mdiggory> 1.) move dspace-services integration into trunk
[16:41] <mdiggory> 1.) add solr integration
[16:41] <mdiggory> sorry that was 2
[16:41] <mdiggory> 3.) XMLUI rendering
[16:41] <mdiggory> 4.) hopefully if time allows JSPUI rendering
[16:42] * grahamtriggs was thinking for a second mdiggory had cloned himself to get it all done in time
[16:42] <mdiggory> I've merged most everything against trunk locally
[16:42] <stuartlewis> I'm sure there's a few of us that can pitch-in for the JSPUI once we've seen how the xmlui works
[16:42] <mhwood> Documentation?
[16:43] <mdiggory> Yea... need that too...
[16:43] <mdiggory> working on it
[16:43] <bradmc> mhwood beat me to it. When / how can you get Jeffrey involved? Would it help?
[16:43] <mdiggory> 1.) Document dspace-services
[16:43] <mdiggory> 2.) Document Statistics Engine
[16:44] <mdiggory> need material for him to edit first
[16:44] <bradmc> (this comment intentionally left blank)
[16:44] <bradmc> Shall we move to Authority Control?
[16:45] <mdiggory> sounds good
[16:45] <mhwood> Thanks mdiggory for all your hard work on that.
[16:45] <bradmc> +35
[16:45] <mdiggory> :-)
[16:45] <lcs_> I've got a little work left, some reworking of confidence thanks to conversation with bollini
[16:45] <stuartlewis> +1 - THANKS :)
[16:45] <grahamtriggs> bradmc: how many of those came from Googlebot?
[16:45] <stuartlewis> I tried authority control after last weeks meeting - worked well.
[16:46] <lcs_> also one problem supporting MSIE; the "lookup" popup breaks in javascript and i can't get a debugger to work on windoze, hoping someone will want to help there.
[16:46] <lcs_> i plan to have the sandbox in a state to merge by tomorrow or friday.
[16:47] <bradmc> Docs?
[16:47] <lcs_> there's the wiki page - updated it last week, although i want to add a bit more abotu confidence
[16:48] <lcs_> the wiki page explains configuration and use as well as theory
[16:48] <bradmc> Okay, thanks. I'll assume Jeff will pick it up. Shall we toss out some possible freeze dates?
[16:49] <bradmc> (for 1.6)
[16:49] <grahamtriggs> can we have a reminder of the wiki link for the lazy? :)
[16:49] <lcs_> http://wiki.dspace.org/index.php/Authority_Control_of_Metadata_Values
[16:49] <stuartlewis> Just a side note - there have been further problems with the DSpace wiki object cache table filling up - Alex @ MIT is on the case.
[16:50] <bradmc> Okay, thanks stuart.
[16:50] <bradmc> I see the issue with the jira email, BTW, I'll get it fixed shortly.
[16:51] <stuartlewis> Great :)
[16:51] * bradmc pulls a totally arbitrary date of of the air: Freeze 1.6 in one week on Wed Sep 7.
[16:52] <bradmc> of of = out of
[16:52] <bradmc> Sep 7 = Oct 7
[16:52] <mhwood> Sep = Oct
[16:52] <mdiggory> hmmm
[16:52] <stuartlewis> Sounds good - presumably some of us are packing up a couple of days after that to travel to Gothenburg anyway?
[16:52] <lcs_> that works for me if there's enough time to review the authority control patch.
[16:52] <mdiggory> true, true
[16:53] <mdiggory> lcs_: I say push it in, ask questions later
[16:54] <bradmc> So we place a loose stake in the ground, and wait for it to get lifted and relocated?
[16:54] <bollini> lcs_: the patch is fine we need to test it on Gothenburg ;-)
[16:54] <stuartlewis> I'm hoping to encourage lots of testing at DSUG.
[16:54] <grahamtriggs> Authority control seems important to enough institutes, and close enough to completion to push for it's inclusion, even if it delays the final release date slightly
[16:54] <bollini> I think that stuart need a clear date to make a "good" live cd
[16:55] <stuartlewis> We need a few test instances up and running by then, + the live cd.
[16:55] <stuartlewis> The LiveCD is built by script, including an svn co, so updates aren't too painful.
[16:56] * bradmc suddenly visualizes a Tuesday midnight burning party in Sweden.
[16:56] <grahamtriggs> Is it too late to convert a dsug session into a testathon? :)
[16:56] <stuartlewis> This is only an alpha / beta (call it what you want) release, so if it is a little buggy, I don't think it matters.
[16:56] <mdiggory> yep... simply first "proof" of release process
[16:57] <lcs_> can you put up the livecd as a .iso for download and burn?
[16:57] <stuartlewis> Yes.
[16:57] <bradmc> I have to step away in a minute or two, as always please continue. I think that was the last of the initially offered topics.
[16:57] <stuartlewis> lcs_: Personally I ten to run it via a VM system, so I don't have to reboot.
[16:58] <stuartlewis> and don't have to burn it.
[16:58] <mdiggory> I have several of those ;-)
[16:58] <mdiggory> an nice VMWare image that you don't have to buy would be nice...
[16:58] <stuartlewis> And it runs quicker having the ISO on hard disk, rather than reading off the CD (DVD as it is quite big now!)
[16:59] <stuartlewis> I tried to keep it < 700MB to fit on a CD, but was almost impossible.
[17:00] <stuartlewis> So I have now let it bloat a little, and includes things like OpenOffice so that batch editing via CSV can be done on the live CD, and it includes a PHP SWORD client + apache2 for demo'ing of SWORD.
[17:00] <grahamtriggs> speaking of VMs, spinning up a test instance would be a good use of a cloud service...
[17:00] <mdiggory> Hmm, I have a CentOS Postgres Image thats only about 125M
[17:00] <lcs_> i've used a java SWORD client for testing, but it was painful
[17:01] <mdiggory> lord... no wonder
[17:01] <stuartlewis> Rough instructions for how to auto build one are here: http://wiki.dspace.org/index.php/LiveCD (a bit out of date now by a few weeks)
[17:01] <stuartlewis> mdiggory: Does it include X, a WM, FireFox etc?
[17:01] <bollini> I need to leave... thanks all
[17:02] <stuartlewis> lcs_: This is a new configurable (a bit like configurable submission in DSpace) SWORD client that is waaaay nicer to use than the client. Even does all the packaging etc for you.
[17:02] <stuartlewis> Thanks Andrea. Bye.
[17:02] * bollini (n=chatzill@host113-233-dynamic.11-87-r.retail.telecomitalia.it) Quit ("ChatZilla 0.9.85 [Firefox 3.0.14/2009082707]")
[17:02] <mdiggory> that'll do it... how about a "skinny image" linux + java + tomcat + postgres
[17:02] <mdiggory> thats it
[17:03] <lcs_> if you just run a DSpace server it could be small, and run it under vmware player so your regular machine is the client.
[17:03] <mdiggory> right... thats what I do now...
[17:03] <stuartlewis> lcs_ / mdiggory: Good idea, but harder for Joe Public to use. Mine, although bigger, boots up into a window manager, auto-launches firefox, and opens tabs for the different interfaces etc.
[17:04] <mdiggory> currently base build on Turnkey Appliance in the VMWare community applicances site
[17:04] * stuartlewis dreams of 'mvn build-livecd'
[17:04] <lcs_> we can have two livecd's: fat man and little boy
[17:05] <stuartlewis> mdiggory: Are you the fat man, or the little boy? Not sure which I'd prefer to be! :)
[17:05] <mdiggory> hey, who you callin "fat"
[17:05] <stuartlewis> Me (I think!). He's calling you 'little boy'!!!
[17:05] <lcs_> have you no sense of history? those were the names of the first atomic bombs.
[17:05] <mdiggory> we do not need to go there...
[17:05] <mdiggory> remember this is a logged channel
[17:06] <mdiggory> lcs_: only you would know that ;-)
[17:06] <mhwood> So we need a discontinued one to be "thin man"?
[17:06] <stuartlewis> Back to work then - we all have committing to do..... :)
[17:06] <mdiggory> or... burning man
[17:06] <lcs_> i had a question about committing:
[17:06] <mdiggory> yes?
[17:07] <lcs_> got proposed patches for ds-285, ds-128, ds-288 but since mail isn't going out perhaps nobody noticed..
[17:08] <stuartlewis> No - didn't notice.
[17:08] <mdiggory> probibly not
[17:08] <lcs_> does anyone want to review them before i commit?
[17:08] <mdiggory> I also recalled that I agreed to commit a few of your patches back before the commiter vote...are we refering to those?
[17:08] <lcs_> i think i reassigned those to myself.
[17:09] <mdiggory> thats why I got confused when looking for them
[17:09] <stuartlewis> 128 (Anchors in submission). When you say it 'sorta works' - what does that mean?
[17:09] <stuartlewis> Does it break any more than it is already broken, or does it screw up completely?
[17:10] <stuartlewis> If it breaks less than it is broken now, might as well commit I suppose?
[17:10] <lcs_> at worst it is like the current behavior, and on firefox3 and msie it works.
[17:10] <stuartlewis> So no error messages etc? That's good.
[17:10] <mdiggory> http://jira.dspace.org/jira/browse/DS-285
[17:10] <stuartlewis> lcs_: DId you see my comment about DS-288?
[17:11] <mdiggory> I want to look at a little
[17:11] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[17:11] <stuartlewis> http://jira.dspace.org/jira/secure/ViewProfile.jspa?name=stuartlewis added a comment - 28/Sep/09 11:21 PM
[17:11] <stuartlewis> Would it be possible and/or desirable to move the logic up into item.getMetadata() so that any code that grabs metadata from the database will apply these rules?
[17:12] <lcs_> i thought about that but it could spawn a lot of new bugs. it shouldn't affect the crosswalks, for instance.
[17:12] <mdiggory> whats that?
[17:12] <mdiggory> 288?
[17:12] <lcs_> hmm, i set watches on those bugs but of course that isn't sending mail either.
[17:12] * bradmc (n=bradmc@207.172.69.79) has joined #duraspace
[17:13] <stuartlewis> mdiggory: Yeah - 288
[17:14] <mdiggory> I'm a little warry about pushing it up there
[17:14] <lcs_> on the other hand it _is_ getting hacky to try to plug leaks in all the dissemination UIs
[17:14] <mdiggory> I don't nat to create multiple access control mechanisms in the core
[17:14] <lcs_> "metadata just wants to be free"
[17:14] <mdiggory> nat = want
[17:15] <mhwood> Data stewards want it chained up, unfortunately.
[17:15] <mdiggory> it shouldn't be stored in metadata in the first place
[17:15] <mdiggory> chained up... I say... wiped out
[17:16] <lcs_> yeah, i've noticed the fields people want to hide are often the ones which are really administrative MD, not descriptive MD, and thought briefly about flagging them that way..
[17:17] <mdiggory> admin MD probibly best stored away from Item in an appropriate service
[17:17] <mdiggory> and access to that service controlled
[17:17] <stuartlewis> bradmc: How did the 1.6 webinar go?
[17:18] <mdiggory> I think patching the holes is acceptable for now
[17:18] <mdiggory> rearchitect and consider for 2.0
[17:19] <mhwood> Yeah, it needs to be addressed in a comprehensive fashion eventually -- this won't go away.
[17:20] <mhwood> Sorry, must go. Thanks all!
[17:21] * mhwood (i=mwood@mhw.ulib.iupui.edu) Quit (Remote closed the connection)
[17:23] <lcs_> So on http://jira.dspace.org/jira/browse/DS-285 (If-Modified-Since behavior for XMLUI) it all works _except_ Cocoon insists on setting the Last-Modified header on Item splash pages. Since that is always later than the real last-modified date anyway it still works for the goal of letting search engines skip over unmodified objects.
[17:23] <lcs_> Any ideas on talking sense into Cocoon?
[17:27] <mdiggory> and the Last-Modified date is later? as in teh current date?
[17:28] <lcs_> yeah, cocoon forces it to the current time, because of caching. but not on Bitstream responses, since those come from a different generator.
[17:29] <mdiggory> and a non-caching pipeline
[17:30] <mdiggory> thing is... I know we are dumping things into the generated pages that may have differing "Last-Modified times than the item content itself
[17:30] <mdiggory> But doesn't that trigger search engines toa ctually retrieve the content?
[17:31] <mdiggory> a current timestamp in Last-Modified I mean
[17:32] <lcs_> they'll just record that as the last-modified time for that resource, and presumably use that timestamp in the if-modified-since on the next request. so while it's a lie, it doesn't affect the outcome.
[17:34] <mdiggory> caching is critical here, if an aspect does need to regenerate any content at all, the Last Modified should update... not just be based on teh Items last Modified timestamp
[17:36] <mdiggory> which means that the cache validity is critical in assessing the If-Modified-Since logic... but it sounds like something awry in those validity checks
[17:36] <mdiggory> in the default dspace if it is the case that you never get a stable Last-Modified datestamp
[17:37] <lcs_> it looks like cocoon lies to the browser so the browser always reloads and cocoon itself gets to judge cache valididy, which makes sense when you consider that you may have changed logins and have different privileges.
[17:59] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) Quit ("Leaving.")
[18:01] * tdonohue (i=80ae241d@gateway/web/freenode/x-fhaeegaplbvseuby) Quit ("Page closed")
[18:03] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[18:18] * bradmc (n=bradmc@207.172.69.79) Quit (Remote closed the connection)
[18:18] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[18:26] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[18:26] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[18:27] * bradmc_ is now known as bradmc
[18:27] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[18:44] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 113 (No route to host))
[18:44] * bradmc_ is now known as bradmc
[19:01] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[19:01] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:31] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has left #duraspace
[21:00] * ksclarke (n=kevin@adsl-227-149-169.clt.bellsouth.net) has joined #duraspace
[22:19] * ksclarke (n=kevin@adsl-227-149-169.clt.bellsouth.net) Quit (Remote closed the connection)
[22:20] * ksclarke (n=kevin@adsl-227-149-169.clt.bellsouth.net) has joined #duraspace
[23:04] * ksclarke (n=kevin@adsl-227-149-169.clt.bellsouth.net) Quit ("Leaving.")
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.