Timestamps are in GMT/BST.
[0:44] * stuartlewis (n=stuartle@130.216.70.98) Quit (lindbohm.freenode.net irc.freenode.net)
[0:44] * stuartlewis (n=stuartle@130.216.70.98) has joined #duraspace
[1:08] * awoods (n=awoods@pool-96-241-203-77.washdc.fios.verizon.net) Quit (Read error: 110 (Connection timed out))
[3:51] * 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))
[3:51] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[3:51] * bradmc_ is now known as bradmc
[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:58] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[4:58] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:02] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:02] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:03] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:04] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:05] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:06] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:09] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:09] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:10] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:11] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:12] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:13] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:16] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:16] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:18] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:18] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:21] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:22] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:23] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:24] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:25] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:25] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:27] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:27] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:29] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:29] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:30] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:31] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:32] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:33] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:36] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:37] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:40] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:41] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:44] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:44] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:48] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:48] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:49] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:50] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:51] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[5:51] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[7:47] * 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))
[7:47] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[7:47] * bradmc_ is now known as bradmc
[8:08] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:11] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) has joined #duraspace
[9:31] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[9:45] * 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))
[9:45] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[9:45] * bradmc_ is now known as bradmc
[11:43] * 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))
[11:43] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:43] * bradmc_ is now known as bradmc
[14:34] * mdiggory (n=mdiggory@209.242.167.69) has joined #duraspace
[14:54] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[14:59] * mdiggory (n=mdiggory@209.242.167.69) Quit ()
[14:59] <bradmc> Hi folks. DSpace meeting coming up ...
[15:00] * jat_ysu (n=jeffreyt@maag127.maag.ysu.edu) has joined #duraspace
[15:01] <bradmc> We'll try to start in a minute or two. Topics, today?
[15:03] <tdonohue> obvious topic: updates on 1.6 release...
[15:03] <kshepherd> quick stats update will be good, some progress has been made there
[15:03] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[15:03] <stuartlewis> Topic: Larry's feed rew-rite
[15:03] <stuartlewis> re-write*
[15:04] * bradmc stops worrying that I'm on the wrong side of a freenode network cleavage.
[15:04] <kshepherd> heh
[15:04] <bradmc> We haven't done a Jira new issue review in a while. Should we?
[15:04] * kshepherd is slow this morning because the espresso machine was being cleaned.. he had to have a cup of tea instead :/
[15:04] <stuartlewis> DS-361 Merge + Improve Generation of Syndication Feeds http://jira.dspace.org/jira/browse/DS-361
[15:04] <bradmc> Or is 1.6 activity covering that.
[15:05] <stuartlewis> A little cleanup might be good.
[15:05] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[15:05] <tdonohue> a little cleanup is always good in my opinion :)
[15:07] <bradmc> Okay, let's run a quick review until 3:20 or so. My search nets 13 issues from DS-340 up to DS-367. That sound right?
[15:07] <bradmc> Who wants to seed issues, who wants to summarize?
[15:07] <bradmc> (I can do either)
[15:07] <mdiggory> Are we starting an hour earlier now?
[15:08] <bradmc> No, we're at 20:00 UTC :)
[15:09] <stuartlewis> http://jira.dspace.org/jira/browse/DS-340 DSpace services log to the command line
[15:09] <mdiggory> darn you google calendar...
[15:09] <mdiggory> it seems an hour off in my view...
[15:10] <mdiggory> glad I was thinking of showing up early
[15:10] <kshepherd> hrm, it's got the right time for me
[15:10] <tdonohue> mdiggory: are you talking the duraspace public calendar? it should be updated now...it was off as of this morning though
[15:10] <jat_ysu> mdiggory: it's the EST time reset that goofs you up.
[15:10] <bradmc> That was 60 secs on DS-340 if Stuart is seeding the issue review ...
[15:11] <bradmc> Yes, I had to adjust the calendars.
[15:11] <stuartlewis> Shall we try that one again? :) http://jira.dspace.org/jira/browse/DS-340 DSpace services log to the command line
[15:11] <mdiggory> DS-340... someyhing for me to look at...
[15:11] <kshepherd> +1 something for mdiggory to look at ;)
[15:11] * kshepherd hides
[15:11] <mhwood> Needs a desired behavior.
[15:11] * mdiggory thwack
[15:12] <stuartlewis> OK - assigned to mdiggory :) Thanks
[15:12] <tdonohue> +1 for mark
[15:12] <stuartlewis> http://jira.dspace.org/jira/browse/DS-341 Patch to add percentage relevance to the search results (JSPUI only)
[15:13] <bradmc> DS-340: +2 mdiggory assigned.
[15:13] <tdonohue> 0 - has anyone tried it out?
[15:13] <mdiggory> DS-341, only for JSPUI...
[15:13] <lcs> -1 hold for UI parity
[15:14] <mhwood> 0
[15:14] <bradmc> DS-341: -1, add note indicating need for XMLUI patch for inclusion.
[15:14] <stuartlewis> 0
[15:14] <stuartlewis> http://jira.dspace.org/jira/browse/DS-343 Patch to hide empty Communities/Collections on JSPUI
[15:14] <stuartlewis> lcs: Do you reckon you'll have the time to handle the xmlui port before 1.6?
[15:15] <mdiggory> I'd like to see it held for more reasons than UI parity... feel lots may change in terms of Search/Browse in future DSpace versions...
[15:15] <mhwood> 0
[15:15] <lcs> i can look at this soon, will try.
[15:15] <bradmc> DS-343: extra minute
[15:15] <lcs> mdiggory: was taht about 343 or 341?
[15:15] <mdiggory> 343
[15:15] <mdiggory> no sorry
[15:15] <mdiggory> 341
[15:16] <tdonohue> DS-343: 0 - sounds useful, but should have UI parity (or at least a how-to on implementing in XMLUI)
[15:16] <bradmc> DS-343: 0, add note indicating need for XML solution as well.
[15:16] * mdiggory is getting wrried about all the handles showing up in dspace.cfg
[15:16] * tdonohue agrees with mdiggory
[15:16] <mdiggory> its a clear sign something is being approached wrong
[15:17] <bradmc> DS-341: mdiggory to add note with other concerns about search/browse
[15:17] <stuartlewis> http://jira.dspace.org/jira/browse/DS-344 Apostrophe in email address prevents EPerson from being selected
[15:17] <stuartlewis> Sorry - that one is resolved
[15:17] <stuartlewis> http://jira.dspace.org/jira/browse/DS-345 Updates in administrative metadata (i.e. dc.description.provenance field) when editing from admin-pages
[15:18] <stuartlewis> 0 - we need a good long discussion about provenance info after 1.6
[15:18] <tdonohue> 0 - I agree with stuartlewis. this is a larger problem
[15:18] <mhwood> 0
[15:18] <lcs> 0 agreed
[15:18] <mdiggory> agree... should have project to remove provenance info from item metadata in future
[15:18] <mdiggory> 0
[15:19] <lcs> well, think about separating administrative, preservation, technical metadata..
[15:19] <jat_ysu> why remove provenance? You need it for historical value.
[15:19] <bradmc> DS-345: 0 Indicate post-1.6, need for discussion on provenance.
[15:19] <mhwood> Yes, one could argue that provenance is being misused.
[15:19] <lcs> this is why it has to be a later discussion. metadata is religious
[15:19] <jat_ysu> Yes..that's very true. Larger discussion needs to take place of what provenance is and isn't
[15:20] <mhwood> Think of the difference between "how it got into DSpace" and "how it got into the organization's hands".
[15:20] <stuartlewis> http://jira.dspace.org/jira/browse/DS-346 Refactor UploadStep to let a subclass decide whether a file upload is required
[15:20] <mdiggory> remove provenance from the publically exposed metadata, not from DSpace
[15:20] <mdiggory> I.E. it shouldn't be descriptive metadata...
[15:20] <lcs> next issue?
[15:20] <stuartlewis> http://jira.dspace.org/jira/browse/DS-346 Refactor UploadStep to let a subclass decide whether a file upload is required
[15:20] <stuartlewis> +1
[15:20] <mdiggory> should be administrative and stored in a history system... agree move on
[15:20] <tdonohue> DS-346: +1 - this seems like a simple, useful patch
[15:21] <mhwood> +1
[15:21] <jat_ysu> +1
[15:21] <lcs> +1, i'll be happy to check it in , then
[15:21] <bradmc> DS-346: +4, lcs to check in.
[15:21] <mdiggory> is this a plugin?
[15:21] <stuartlewis> http://jira.dspace.org/jira/browse/DS-347 Add --quiet option to MediaFilterManager to disable debug/monitoring output
[15:21] <stuartlewis> +1
[15:22] <tdonohue> +1
[15:22] <kshepherd> +1
[15:22] <mhwood> +1 wanted that for a long time
[15:22] <lcs> +1, will checkin too
[15:22] <bradmc> DS-347: +5, lcs to checkin.
[15:22] <stuartlewis> http://jira.dspace.org/jira/browse/DS-349 Edit Item in admin UI does not allow setting Bitstream to an Internal BitstreamFormat
[15:22] <lcs> mdiggory: 346 is just subclassing, the other one is a plugin
[15:23] <stuartlewis> +1
[15:23] <mhwood> +1
[15:23] <mdiggory> +1
[15:23] <lcs> +1
[15:23] <tdonohue> +1 (does this work right in JSPUI?)
[15:23] <lcs> it's not an issue in JSPUI :-)
[15:23] <tdonohue> ok
[15:24] <bradmc> DS-349: +5, lcs to progress.
[15:24] <lcs> (unfortunately because you have to set a raw format id number)
[15:24] <stuartlewis> http://jira.dspace.org/jira/browse/DS-350 Plugin Interface to add Custom Data Types to Configurable Submission Forms
[15:24] <stuartlewis> This is just a future-feature, 'please vote' stub
[15:25] <stuartlewis> http://jira.dspace.org/jira/browse/DS-351 Ban empty catches from the code
[15:26] <stuartlewis> The example given is from databasemanager:
[15:26] <stuartlewis> try
[15:26] <stuartlewis> {
[15:26] <stuartlewis> statement.close();
[15:26] <stuartlewis> }
[15:26] <stuartlewis> catch (SQLException sqle)
[15:26] <stuartlewis> {
[15:26] <stuartlewis> }
[15:26] <mdiggory> DS-350 seems to be just a couple of interfaces...
[15:26] <kshepherd> there was a question on the mailing list this morning about DSpace exception handling convention, as well
[15:26] <bradmc> DS-351: extra min
[15:26] <stuartlewis> e.g. Are we happy that this sort of catch is just there to catch if the statement has already been closed, or does it need further handling?
[15:27] <mdiggory> DS-351 "Ban" is harsh, there may be places where it acceptable to just continue without issue
[15:27] <lcs> it ought to have an explanation of why it's OK to do nothing.
[15:27] <bradmc> +1 lcs
[15:27] <mdiggory> agree
[15:27] <tdonohue> it might be worth broader discussion about conventions/best practices...
[15:27] <stuartlewis> This is probably a bigger debate - needs w hole meeting itself for coding conventions and quality standards.
[15:27] <mhwood> +1 lcs
[15:27] <stuartlewis> So how do we handle this in JIRA now?
[15:27] <lcs> +1 stuartlewis -- though there are sorta-loose conventions now.
[15:27] <stuartlewis> Leave the issue open, or close saying we'll revisit, etc?
[15:27] <mdiggory> Its not a fix...
[15:27] <bradmc> DS-351: Add note indicating a discussion is warranted.
[15:28] <mdiggory> Its a comment
[15:28] <kshepherd> seems like the sort of thing that should be in a developers guide or the wiki
[15:28] <kshepherd> the "if you have an empty catch, explain why" convention, that is
[15:28] <bradmc> DS-351: Keep it open until discussion, or we add to someplace that we can stick a link to.
[15:28] <stuartlewis> http://jira.dspace.org/jira/browse/DS-352 Outgoing emails: Storing them and User Interface to view
[15:28] <bradmc> We are already 5 min over, but rolling; have about 8 left to go. Continue or stop?
[15:28] <mdiggory> log to debug... is probibly the appropriate convention
[15:28] <bradmc> (After 352)
[15:29] <stuartlewis> Stop?
[15:29] <stuartlewis> Loads of other things to talk about - can always carry on later if time left at end
[15:29] <bradmc> Stop after 352 in one min.
[15:29] <tdonohue> stop...we can continue more next week
[15:29] <mdiggory> storing emails where?
[15:29] <lcs> 352: this is out of scope for dspace. the site should run a local MTA and use mail aliases to copy messages to files
[15:29] <stuartlewis> 352 is all to do with provenance again.
[15:29] <stuartlewis> CLose and refer to 345?
[15:30] <jat_ysu> 352 IMHO has to do with legal issues and is way wider than we have time to discuss here.
[15:30] <bradmc> DS-352: Mark won't fix, close, add a note about out of scope, and refer to DS-345.
[15:30] <tdonohue> yea, close and refer to 345 sounds right
[15:30] <bradmc> Okay, 1.6 status updates, including recent statistics activity...
[15:31] <stuartlewis> Not sure there is much to say on 1.6 as such. Just waiting for stats now.
[15:31] <mdiggory> moved XMLUI statistics to separate view/page
[15:31] <mdiggory> externalized strings to messages.xml
[15:31] <mdiggory> have three additional "listings" on the way
[15:31] <stuartlewis> kshepherd has been developing the JSPUI too, and has a working version.
[15:31] <kshepherd> doing the same for JSPUI, keeping up to date with XMLUI views, won't be much longer
[15:31] <mdiggory> by country, by city and downloads per item
[15:32] <stuartlewis> I've been working on a dspace.log->intermediate log format->solr convertor
[15:32] <stuartlewis> Does anyone here have a wave account? We've been trying wave as a way of more richly (than JIRA can issue) discussing issues.
[15:32] <mdiggory> doing some minor enhancement to to the pageMeta for identifying the containerType and objectType for DSpaceObjects being viewed.
[15:33] <bradmc> Brad, Stuart, Mark, Kim all waving at each other, BTW.
[15:33] <tdonohue> i'm still waiting on my wave invite :(
[15:33] <bradmc> Stuart, was DS-361 (syndication feeds) a topic request, or the start of an issue review?
[15:34] <stuartlewis> ds-361: A big potential 1.6 issue for us to discuss.
[15:34] <bradmc> Let's go to that, then.
[15:34] <stuartlewis> Outgoing emails: Storing them and User Interface to view Merge + Improve Generation of Syndication Feeds
[15:34] <mdiggory> Unfortunately... unlike GMAil, invites are a bit more controlled in Wave
[15:34] <stuartlewis> Agh!
[15:35] <stuartlewis> http://jira.dspace.org/jira/browse/DS-361 Merge + Improve Generation of Syndication Feeds
[15:36] <mdiggory> seems fairly consolidated to the Feed classes
[15:36] <stuartlewis> +1 seems a good idea
[15:36] <kshepherd> i like the idea, haven't tested
[15:36] <lcs> yeah, it's quite isolated, in fact, i backported it to 1.5.2 with no trouble.
[15:37] <lcs> the only big issue is that xmlui still ignores harvest.includerestricted.rss
[15:37] <mdiggory> question: What about ORE fields...
[15:37] * mdiggory ducks
[15:37] <stuartlewis> lcs: Is that easy to fix do you think?
[15:38] <lcs> it probably is easy, just steal the code from jspui, i haven't had time tho.
[15:38] <stuartlewis> IIRC it works via the Harvest class (just an extra parameter to the harvest method)
[15:38] <stuartlewis> Do the xmlui use the Harvest class to generate feeds?
[15:39] <lcs> xmlui calls browse engine directly,t hat's the problem.
[15:39] <stuartlewis> I see.
[15:39] <lcs> there's also your idea to enable feeds by default.
[15:39] * 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))
[15:39] <stuartlewis> Ah yes: Is everyone OK if we enable feeds by default now?
[15:39] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:39] <mdiggory> Does the Harvest class use the Browse system?
[15:39] <tdonohue> +1 to enabling feeds by default
[15:39] <mhwood> 0 enable by default
[15:40] <lcs> +1 to enable feeds by default
[15:40] <kshepherd> +1 to default feeds
[15:40] <stuartlewis> see: http://blog.stuartlewis.com/2008/12/15/enable-your-repository-to-feed-the-world/
[15:41] <mdiggory> Confussed, are we refering to the Harvest class that is part of the TAMU Harvest addition?
[15:41] <stuartlewis> "Of the 26 UK DSpace repositories listed in ROAR, only 8 had working RSS feeds!"
[15:41] <mdiggory> +1 enable them
[15:41] <stuartlewis> +1
[15:41] <tdonohue> stuartlewis: wow...embarrassing
[15:42] <lcs> mdiggory: org.dspace.search.Harvest
[15:42] <bradmc> So what disposition are we looking for here. We seem to want DS-361, presumably for 1.6; do we wait on the harvest.includerestricted.rss xmlui issue or not?
[15:42] <mdiggory> ok... we need to consider that we are having classes with the same name showing up in dspace-api
[15:42] <mdiggory> https://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/app/harvest/Harvest.java
[15:42] <mdiggory> https://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/search/Harvest.java
[15:43] <mdiggory> this is a bad practice
[15:43] <jat_ysu> ouch.
[15:43] <mhwood> I would have said, that's not the same name: app/harvest != search
[15:43] <mdiggory> lets not mince words
[15:44] <mdiggory> ;-)
[15:44] <stuartlewis> Am I right in thinking includerestricted does not work in xmlui now? So by not including it, we're not breaking anything, just giving us a better pltaform to move forward with?
[15:45] <lcs> stuartlewis: correct
[15:45] <mdiggory> o.d.s.Harvest appears specifically for the OAI webapp... specifically for efficiency in generating output?
[15:45] <tdonohue> stuartlewis: yes, i think that's true...we could move forward with DS-361 and log a bug that the XMLUI doesn't obey includerestricted (to be fixed later)
[15:45] <kshepherd> mdiggory: there's also a org.dspace.harvest package, just to confuse matters more ;)
[15:46] <mdiggory> I want to focuse briefly on how much o.d.s.Harvest is being used?
[15:46] <lcs> i will fix it if i have time.. would have to test it too, though.
[15:47] <bradmc> I'd like to avoid creating gating issues for 1.6, so I like the idea of going with DS-361, adding another bug, and if LCS gets to it in time, all the better.
[15:47] <stuartlewis> +1
[15:47] <lcs> +1
[15:47] <tdonohue> +1
[15:47] <mhwood> +1, those are really separate issues
[15:47] <kshepherd> +1
[15:48] <mdiggory> +0
[15:48] <bradmc> Do we need an initiative or bug to rename our Harvests?
[15:48] <stuartlewis> includerestricted is quite a hack, with bad performance, so another topic post-1.6: trying to get some sort of authZ info into the browse data.
[15:48] <tdonohue> bradmc: i was just going to suggest putting something in Jira regarding those
[15:49] <tdonohue> mdiggory, do you want to log a Jira issue regaring the various Harvest classes and a possible refactoring?
[15:49] <mdiggory> stuartlewis: tdonohue yes
[15:50] <mhwood> Is it that big a deal? I'm tinkering with CORBA just now, and keenly aware that both Java and CORBA define a class named Object, but it's a minor annoyance.
[15:50] <lcs> mdiggory: might as well see if there are any other duplicate names within dspace-api. i guess Item/Item doesn't count.
[15:51] <tdonohue> mhwood: in either case probably worth opening up an issue for further discussion, etc.
[15:51] <mdiggory> I suspect there are a number of conflations
[15:51] <bradmc> mhwood: Those two namespaces come from different organizations. It's a little more embarassing when you name all your own children the same.
[15:52] <lcs> when you can avoid creating collisions from the outset, i think it's worthwhile, but i'm not gonna ask to rename wing.List and wing.Item...
[15:52] <mhwood> I have the same quarrel with our enterprise directory folk: a thing's name is its DN, not its RDN.
[15:52] <bradmc> +1 lcs on pragmatism here.
[15:52] <mdiggory> lcs I tend to agree... htat was a bad naming choice
[15:53] <mdiggory> Ideally, we would deprecate those classes and create new ones that do the same
[15:53] <bradmc> I think we hit all the topics declared up front. What else for today?
[15:54] <mdiggory> utilize a the new ones as superclasses of the old badly named ones.
[15:54] <mdiggory> and tehn set a termination date for the old ones
[15:54] <stuartlewis> Could we discuss this one quickly: http://jira.dspace.org/jira/browse/DS-354 Make-handle-server configuration fails. Using manual commands instead of script is successful.
[15:55] <mdiggory> Testing out the Harvester addition... I opened a ticket on it not working with OAI gateways that don't use sets
[15:55] <kshepherd> mdiggory: when i was first testing the harvester, it was a very simple hack to make specifying a target set optional..
[15:55] <kshepherd> maybe i can dig up that patch again
[15:56] <mdiggory> stuartlewis: could you add a "dspace" command for that in the wrapper you wrote
[15:56] <lcs> ds-354: doesn't hte launcher improve the situation?
[15:56] <mdiggory> kshepherd: thanks, that would be a great addition if you have it
[15:56] <mdiggory> and save me writing it
[15:56] <stuartlewis> mdiggory: Yes, but it will be running net.handle.server.SimpleSetup (and not answering the questions automatically for you)
[15:57] <jat_ysu> You'll still need to tell it where you put your handle-server directory
[15:57] <mdiggory> so create-administrator is interactive... Maybe we need a wrapper for SimpleSetup that is interactive?
[15:57] <mhwood> Automatic answering seems fragile. The questions can change in almost any way as the Handle package evolves.
[15:57] <stuartlewis> mdiggory: We have one, but it is broken
[15:57] <jat_ysu> The current script does that, but it fails
[15:58] <mdiggory> is it in java?
[15:58] <stuartlewis> No - .sh
[15:58] <stuartlewis> So yeah - best fix might be to rewrite in java?
[15:58] <mdiggory> the wrapper would/should be java based
[16:00] <jat_ysu> Isn't it just a simple to run the one command line and inconvenience the user once in the dspace career?
[16:00] <jat_ysu> the=their
[16:00] * stuartlewis fears we inconvenience them a little too often! :(
[16:00] <stuartlewis> Buy yeah - can see what you mean.
[16:00] <stuartlewis> but*
[16:01] <mdiggory> inconvenience? I guess its a question of if your getting paid at the same time as being "inconvenienced".
[16:01] <jat_ysu> Look, if I pay US$ 2.5 Million for something I don't want inconvenienced. But if it's free....thats the cost.
[16:01] <mhwood> Hiding all the hair involved in starting up a commandline Java gadget is worth a little effort, but not a huge amount.
[16:02] <mdiggory> jat_ysu: we are talking about fixing up the execution....
[16:02] <jat_ysu> my institution says "we're paying you $$$ to be inconvienced and saving us $$$$$...)
[16:02] <mdiggory> sounds like a convenience to me ;-)
[16:02] <jat_ysu> Yes.....I think that's it.
[16:02] <stuartlewis> So the fix for now -- remove broken make-handle-config, document this, and then open new issue for a Java replacement?
[16:02] <kshepherd> brb
[16:03] <mhwood> How much inconvenience can we take away without spending weeks or months doing so?
[16:03] <jat_ysu> There's the $64000 question
[16:03] <mdiggory> lovely... taking any of this away would be a blessing...
[16:03] <mhwood> In this case, more than 30 minutes is probably worth thinking twice.
[16:03] <mdiggory> awk '/.*/ {print $0} /"server_config" = {/ {printf "\"storage_type\" = \"CUSTOM\"\n\"storage_class\" = \"org.dspace.handle.HandlePlugin\"\n\n",$0}' <$tempfile >$handledir/config.dct
[16:04] <jat_ysu> I'll test if you send it to me....tomorrow.. ;-)
[16:04] <stuartlewis> 'remove, document, new issue for java replacement' +1
[16:04] <jat_ysu> +1
[16:04] <tdonohue> stuartlewis: +1
[16:04] <mhwood> +1
[16:04] <lcs> +1
[16:04] <bradmc> I think the long term goal should be to have DSpace able to be installed via standard distribution packaging mechanisms. But I don't see this as moving us particularly significantly towards or away from that; it's a project in itself for a later date. So removing the broken, add the docs, new issue seems okay. +0
[16:05] <jat_ysu> The idea is to get a clean sitebndl.zip for cnri
[16:05] <mdiggory> We have had a general trand away from shell scripting and bat scipting for commanline interfacing for some time now
[16:05] <mdiggory> this would just be part of that continued activity. and considered a best practice
[16:06] <bradmc> We're at time, now, as usual folks should continue until they fizzle.
[16:06] <mhwood> Some of this could be pushed upstream: the sitebndl setup code could be more friendly to scripted installation.
[16:07] <mdiggory> IMO... pushed more "out of stream" as we eventually separate out and away any Handler server integration.
[16:07] <bradmc> I agree, Mark.
[16:07] <bradmc> And Mark.
[16:09] * mdiggory feel like he's trapped in "Being Mark Malkovich"
[16:10] <lcs> hmm, i may be able to look into reviving the pluggable persistent identifier patch for 1.6.1, since we don't use handles here.
[16:10] <mhwood> Then we need a clear idea of how multiple permalink providers will be accommodated in this future DSpace. It may turn out to be simple to drive all of their installers with a common interface. Or it may be not worth the bother; "install the provider of your choice, and it plugs into DSpace like so."
[16:10] <mdiggory> ExternalIdentifiers...
[16:11] <jat_ysu> I don't think you can just de-couple the handle server without having the modularity built in for a migration. Too many of use use Handle
[16:11] <mdiggory> was a prototype in the DAO work between James Rutherford and Richard Jones
[16:11] <jat_ysu> If handle could serve as the first example a pluggable PURL....
[16:12] <mdiggory> jat_ysu: ExternalIdentifiers decoupled and provided continued support for Handle as default implementation
[16:12] <lcs> yeah, i remember. it seemed like a reasonable design, i'm sorry it never got in.
[16:13] <mdiggory> it got tangle up in a very large refactoring of the DSpace codebase... big lesson learned there
[16:13] <jat_ysu> okay
[16:13] <lcs> http://wiki.dspace.org/index.php/PersistentIdentifiers
[16:15] <jat_ysu> I'm reading the wiki now.. I need to study before I put foot back into mouth again.
[16:16] <mdiggory> I wonder if, much like the Fedora folks, we can begin to list possible special topic meetings for addressing these larger scoped projects?
[16:17] <jat_ysu> Might be useful.
[16:17] <jat_ysu> I've got to run...Helga the trainer has an appt with me in 25 min. Enjoy.
[16:17] <mdiggory> These might give folks an opportunity to "catchup" on the details of the topic and give some space to disucss
[16:17] <mdiggory> jat_ysu: Cheers!
[16:18] * jat_ysu (n=jeffreyt@maag127.maag.ysu.edu) Quit ("Leaving")
[16:18] <mdiggory> I still believe that specific portions of the DAO refactoring can still be valuable to us...
[16:19] <mdiggory> And likewsie, we need an "in-group" venue for discussing important activities around DSpace 2.0 development
[16:19] <lcs> yeah, people could prepare for it, marshal their arguments and maybe even reach a concolusion. it would take strong moderation, but better to have a focused meeting as a venue.
[16:19] <bradmc> Seems like a good idea to me.
[16:21] <mdiggory> with the logbot... theres room for later review by folks that were not present.
[16:22] <tdonohue> i like the idea of special topic meetings... assuming we can get "most" of us in IRC at the same time on another day of the week
[16:23] <tdonohue> either that, or tack in on just before/after this meeting, as needed
[16:23] <mdiggory> I tend to agree with the latter.
[16:23] <bradmc> Fedora just designates every 3rd or 4th meeting as a special topics mtg.
[16:23] <bradmc> No rescheduling involved.
[16:23] <bradmc> Although they regularly run to 90 minutes.
[16:23] <mdiggory> but I also understand that might be difficult for those inconvenienced by time zone...
[16:24] <tdonohue> aha...yea, that could work as well (except around release time, maybe)
[16:24] <mhwood> There is a need to tackle larger issues, and they tend to come up anyway and pull the regular meeting out of shape, if you will.
[16:24] <mdiggory> so... it might be a activity within the meeting... like JIRA issues
[16:24] <bradmc> And .. fedora tends to skip special topics mtgs around release time ...
[16:25] <bradmc> Given time constraints, I think when we declare a special topics mtg, we should skip the Jira review.
[16:25] <mhwood> Agree.
[16:25] <tdonohue> i'd agree with that
[16:26] <mdiggory> Like it
[16:26] <tdonohue> maybe we could work on establishing a "special topics meeting" for the first meeting of each month?
[16:27] <tdonohue> that'd give us a month to gather some initial topics, bring up further discussion, and then have the first on on 12/2?
[16:27] <mhwood> How do special topics get scheduled?
[16:28] <tdonohue> Jira maybe?
[16:28] <bradmc> Ideas come up in reg meetings, are collected on a wiki page, then the Fedora coordinator suggests a few topics at a reg mtg, one is selected, and announced.
[16:29] <mdiggory> bradmc: sensible...
[16:29] <mhwood> Sounds reasonable.
[16:29] <bradmc> +1 tdonohue
[16:29] <bradmc> (12/2)
[16:31] <tdonohue> if we want to use the Wiki, I can start up a Wiki page based on the topics that came up today... thoughts?
[16:31] <bradmc> +1
[16:31] <mhwood> Thank you.
[16:33] <mhwood> Maybe with a date stamp when a topic enters the list, so we can see if some topics are being starved?
[16:33] <lcs> persistent identifiers might be a good trial run topic. metadata is the third rail of repository discussions.
[16:34] <lcs> .. or perhaps the exception handling that was just brought up.
[16:34] <bradmc> Tansley at DSUG: "If metadata isn't boring, you're doing it wrong" ;)
[16:35] <tdonohue> would Jira be helpful here at all (in keeping topics separate and date/time stamped, etc.?) Just trying to think of all our options...though we can always start with the Wiki and see how it works out
[16:35] <bradmc> I think you're going to want the looseness of the Wiki.
[16:35] <mdiggory> exception handling would be more part of an overal "best practicies" "developer guidence" discussion I think
[16:36] <mhwood> I'm still not familiar enough with Jira. We'd need a way to group special topics so we can retrieve them all together spearate from other items. Wiki may be easier.
[16:36] <mdiggory> persistent Identifiers is good, there are also related portions of DSpace 2.0 that should be included in such a topic
[16:36] <lcs> I think we should start with something relatively harmless and lightweight to get a feel for the mechanism, without going overboard into the content.
[16:37] <tdonohue> we'll just go wiki for now, then. I think bradmc is right about looseness being a factor
[16:37] <mdiggory> agree
[16:37] <tdonohue> lcs: definitely agreed
[16:38] <lcs> agreed on the wiki
[16:40] <tdonohue> ok, i can start up our wiki page, and send off a summary of what we just discussed to dspace-devel
[16:46] <mhwood> Sounds good. Thanks again.
[16:46] <lcs> yeah, thanks!
[16:48] <tdonohue> no problem
[17:09] * mhwood (i=mwood@mhw.ulib.iupui.edu) Quit (Remote closed the connection)
[17:18] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) Quit ("Leaving.")
[17:41] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Remote closed the connection)
[18:25] * stuartlewis (n=stuartle@130.216.70.98) Quit (leguin.freenode.net irc.freenode.net)
[18:26] * justben (n=ben@hypatia.library.emory.edu) Quit ("Leaving.")
[18:37] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:35] * 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))
[19:35] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:36] * bradmc_ is now known as bradmc
[20:14] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) Quit ("Leaving...")
[20:33] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Read error: 110 (Connection timed out))
[21:06] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) has joined #duraspace
[21:11] * ksclarke (n=kevin@adsl-21-143-19.clt.bellsouth.net) has joined #duraspace
[21:20] * lcs (n=lcs@serenity.hul.harvard.edu) Quit ()
[22:28] * greg-g (i=greg@ubuntu/member/greg-g) Quit (leguin.freenode.net irc.freenode.net)
[22:28] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (leguin.freenode.net irc.freenode.net)
[22:28] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit (leguin.freenode.net irc.freenode.net)
[22:28] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[22:28] * ChanServ (ChanServ@services.) Quit (leguin.freenode.net irc.freenode.net)
[22:28] * krnl__ (i=krnl_@193.219.158.144) Quit (leguin.freenode.net irc.freenode.net)
[22:29] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[22:29] * krnl__ (i=krnl_@193.219.158.144) has joined #duraspace
[22:29] * greg-g (i=greg@ubuntu/member/greg-g) has joined #duraspace
[22:29] * ChanServ (ChanServ@services.) has joined #duraspace
[22:29] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[22:29] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[22:30] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[22:35] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit (Client Quit)
[23:09] * ksclarke (n=kevin@adsl-21-143-19.clt.bellsouth.net) Quit ("Leaving.")
[23:09] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) has joined #duraspace
[23:10] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) Quit ("Leaving...")
[23:20] * mdiggory (n=mdiggory@cpe-76-176-9-20.san.res.rr.com) Quit ()
[23:32] * 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))
[23:32] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[23:32] * bradmc_ is now known as bradmc
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.