Timestamps are in GMT/BST.
[2:00] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[3:15] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit ()
[3:53] * scottatm (n=scottatm@peat.evans.tamu.edu) Quit (leguin.freenode.net irc.freenode.net)
[3:53] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[3:53] * ChanServ (ChanServ@services.) Quit (leguin.freenode.net irc.freenode.net)
[3:53] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit (leguin.freenode.net irc.freenode.net)
[3:53] * cbeer (n=cbeer@146.115.109.46) Quit (leguin.freenode.net irc.freenode.net)
[3:54] * ChanServ (ChanServ@services.) has joined #duraspace
[3:54] * scottatm (n=scottatm@peat.evans.tamu.edu) has joined #duraspace
[3:54] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[3:54] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[3:54] * cbeer (n=cbeer@146.115.109.46) has joined #duraspace
[4:06] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[6:22] * grahamtriggs (n=trig01@80.169.130.178) has joined #duraspace
[7:11] -christel- [Global Notice] Hi all, In preparation for the weekend's ircd migration we will need to take some servers out of production for upgrades, I am about to do a spot of rehubbing to continue the upgrades now. This may raise the number of splits for the next day, more information as and when will be available via wallops. Thank you for using freenode and have a great day.
[7:12] * scottatm (n=scottatm@peat.evans.tamu.edu) Quit (leguin.freenode.net irc.freenode.net)
[7:12] * grahamtriggs (n=trig01@80.169.130.178) Quit (leguin.freenode.net irc.freenode.net)
[7:12] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (leguin.freenode.net irc.freenode.net)
[7:12] * ChanServ (ChanServ@services.) Quit (leguin.freenode.net irc.freenode.net)
[7:12] * cbeer (n=cbeer@146.115.109.46) Quit (leguin.freenode.net irc.freenode.net)
[7:12] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit (leguin.freenode.net irc.freenode.net)
[7:12] * ChanServ (ChanServ@services.) has joined #duraspace
[7:12] * grahamtriggs (n=trig01@80.169.130.178) has joined #duraspace
[7:12] * cbeer (n=cbeer@146.115.109.46) has joined #duraspace
[7:12] * scottatm (n=scottatm@peat.evans.tamu.edu) has joined #duraspace
[7:12] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[7:12] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[7:38] * awoods (n=awoods@pool-72-66-126-180.washdc.fios.verizon.net) has joined #duraspace
[8:03] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:30] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:53] * barmintor (i=barminto@specdl11.cul.columbia.edu) has joined #duraspace
[12:12] * grahamtriggs (n=trig01@80.169.130.178) has left #duraspace
[13:34] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[13:44] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[14:35] * keithg (n=keith-no@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[14:46] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[14:53] * cccharles (n=user@131.104.62.47) has joined #duraspace
[14:57] * bollini (n=chatzill@host102-175-dynamic.17-87-r.retail.telecomitalia.it) has joined #duraspace
[14:58] * kshepherd grabs a coffee
[14:58] <stuartlewis> For me? How kind! :)
[14:58] <kshepherd> you wish ;)
[14:58] <tdonohue> Hi all...DSpace Dev meeting starting here in a few minutes. I sent an agenda to dspace-devel: https://sourceforge.net/mailarchive/forum.php?thread_name=4B606571.4050100%40duraspace.org&forum_name=dspace-devel
[14:59] <kshepherd> i have to juggle this meeting with our monthly staff forum, so i might not be super-responsive.. but i will be here.. taking my laptop into the lecture theatre after my coffee
[14:59] <kshepherd> back soon
[14:59] <tdonohue> I'd also like to tack onto the agenda some discussion of DS-470 (which has gotten a lot of talk on dspace-devel). But, we'll do that after 1.6 updates and Graham's proposal
[14:59] * caryn (i=80c8e115@gateway/web/freenode/x-pxujsfhxtjretchz) has joined #duraspace
[15:00] <tdonohue> Well, looks like we are at the top of the hour. Stuart, shall we start with general 1.6 updates first, before more in depth proposal discussion?
[15:01] <stuartlewis> OK.
[15:01] <stuartlewis> Let's run through the outstanding JIRA issues... should be quick, many have been closed since last wee.
[15:01] <stuartlewis> s/wee/week
[15:01] <stuartlewis> THanks for all the effort on closing the issues.
[15:01] <stuartlewis> http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10020&fixfor=10020
[15:02] <stuartlewis> Doc issues we can ignore.
[15:02] * richardrodgers (n=richardr@dhcp-18-111-11-204.dyn.mit.edu) has joined #duraspace
[15:02] <stuartlewis> Anyone know if mdiggory is hoping to attend?
[15:02] <tdonohue> yes, jeffrey trimble is hard at work on those doc ones...so, we can skip over anything assigned to him.
[15:02] <stuartlewis> DS-440: spiders.txt is empty.
[15:03] <tdonohue> we can follow up with mdiggory offline if he doesn't pop in soon
[15:03] <stuartlewis> Does anyone have lists of spiders we can use?
[15:04] <tdonohue> Depends on the format of spiders.txt. Theres some at http://iplists.com/
[15:04] <stuartlewis> I think for 1.6 we'll just have to ship with a static list.
[15:04] <stuartlewis> IIRC it is one IP (complete, not ranges) per line.
[15:05] <mhwood> Yes, I think right now the question is what we could put in for shipment and what goes in the documentation.
[15:05] <stuartlewis> OK - any volunteers to compile an IP list?
[15:06] <richardrodgers> don't all jump in at once
[15:06] <stuartlewis> We'll leave it assigned to mdiggory then, but if anyone has 15 mins and feels like creating a list, feel free to upload it is a patch to the issue.
[15:07] <tdonohue> http://iplists.com/ has the major spiders listed. But, unfortunately, it's not in the right format.
[15:07] <stuartlewis> http://iplists .com/google.txt - wrong format?
[15:07] <stuartlewis> http://iplists.com/google.txt
[15:08] <mhwood> Some lines are three octets.
[15:08] <kshepherd> re
[15:08] <tdonohue> yea, I think so...since they are not all individual IP address....for instance "209.855.238" is a range which includes 0-255
[15:08] <stuartlewis> Ah right - missed that.
[15:08] <stuartlewis> Oh well - can write a little script to spot them and add them in.
[15:08] <kshepherd> indeed
[15:08] <tdonohue> really, we should be able to just tell people to go to http://iplists.com/ to get the latest lists...it'd be nice if we could accept that format
[15:09] <tdonohue> (but i don't know how much work that would take...if need be, some simple script would also work)
[15:09] <stuartlewis> I might be wrong, but I think the spider detection code is in the external stats module, so updating that is hard, as it requires a release to be made for mvan in trunk to pick up the changes.
[15:10] <tdonohue> aha..ok
[15:10] * jtrimble (n=jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[15:10] <stuartlewis> So maybe stick with 1 IP per line for 1.6?
[15:11] <stuartlewis> The other outstanding issue is http://jira.dspace.org/jira/browse/DS-418
[15:11] <kshepherd> mm, i didn't realise we could match subnets. but i think "stick with current logic" is best given timeframe
[15:11] <kshepherd> s/could/couldn't/
[15:11] <tdonohue> sure, if that's what seems reasonable right now. Just may mean a rather large spiders.txt file :)
[15:11] <kshepherd> yeah :/
[15:11] <stuartlewis> kshepherd: Could you give us a quick update?
[15:12] <kshepherd> yep, although not much to report just yet. it seems like everyone is generally in agreement that we should apply the changes discussed, so i'll make a start on it very soon
[15:12] <stuartlewis> Excellent - thanks.
[15:13] <richardrodgers> any sense of how complex task is - need help?
[15:13] <kshepherd> ETA probably saturday or sunday
[15:13] <kshepherd> richardrodgers: it's more tedious than complex i think, but if i get stuck i'll put my hand up :)
[15:13] <stuartlewis> kshepherd: Thanks :)
[15:13] <tdonohue> sounds good kshepherd. Let us know if anything comes up!
[15:14] <stuartlewis> Finally.... a new proposal from grahamtriggs.
[15:14] <richardrodgers> kshepherd: yea thanks!
[15:14] <stuartlewis> grahamtriggs: The floor is yours...
[15:14] <grahamtriggs> *ahem*
[15:14] <grahamtriggs> ok, so I've been looking at the SWAP profile a lot recently, and associated with that, the Dublin Core metadata recommendations
[15:16] <grahamtriggs> Now, both provide support for an OpenURL context object encoded value as part of the bibliographicCitation field - what's more, SWAP states that an implementation SHOULD include it
[15:16] <grahamtriggs> the OpenURL context object contains a bunch of metadata in a machine readable format that we simply don't have (reliable) access to in any other way
[15:16] <tdonohue> SWAP BiblographicCitation: http://www.ukoln.ac.uk/repositories/digirep/index/Scholarly_Works_Application_Profile#Bibliographic_Citation
[15:17] <tdonohue> DC Recommendations for machine parsable citations: http://dublincore.org/documents/dc-citation-guidelines/#rec4
[15:18] <jtrimble> Graham, would this also make the case or need to overhaul the DC Registry as we currently have it configured in DSpace?
[15:19] <grahamtriggs> we need to have some way of handling this - both accepting SWAP packages (ie. via SWORD) that contain these encoded objects, and being able to output them (ie. in Meta tags), but also be able to use them for OpenURL linking, citation matching, citation downloads....
[15:20] <grahamtriggs> yes, there is a potential DC registry overhaul component to this.... but that's a significant impact, especially as Dublin Core does not anywhere provide for discrete storage of this metadata as separate fields - we would either have to hack it, hack another schema or incorporate others
[15:21] <richardrodgers> I'm not clear on what you are recommending - we are working with BMC for using this additional metadata & will share any enriched crosswalks, etc
[15:22] <grahamtriggs> on the other hand, there are a number of metadata fields that can hold more than one encoding scheme (citation's human readable vs Context Object the immediate example, but there are others).
[15:22] <mhwood> Was the question whether the DC Registry needs changes if we just slip a(nother) value into this field which happens to be OpenURL? I shouldn't think so.
[15:22] <grahamtriggs> and generally, where these fields exist in serializations, the schema is encoded as part of the it
[15:22] <jtrimble> Well, I think, IMHO, we need to look at overhauling DC as we use it in DSpace and use the full DCMI implementation. DSpace's is about 6 years old.
[15:23] <jtrimble> and I realize the impact of what Im saying.
[15:23] <jtrimble> <ducks for cover>
[15:23] <mhwood> We do need to review it but I don't think this forces that review.
[15:23] <caryn> i actually agree, and think it might be useful to come up with a dc application profile (http://dublincore.org/documents/profile-guidelines/index.shtml)
[15:24] <grahamtriggs> so, I would say that it makes sense that we should be able to store as part of a metadatavalue something that describes how the field has been encoded / syntax
[15:25] <stuartlewis> grahamtriggs: Do you want to explain how this is a minor db schema change proposed for 1.6, but nothing in the UIs etc will change. That can come later? So for now, we're making a small change to support bigger changes later.
[15:25] <grahamtriggs> jtrimble: I agree, but I don't want to take that on right now!
[15:26] <grahamtriggs> yes - I would like to see us embrace that we can record the encoding / syntax of a metadatavalue, without worrying about making UI, etc. changes that make use of it right now
[15:27] <jtrimble> well that's one step to harmonization.
[15:27] <grahamtriggs> doing so will allow us to address those issues as minor patches / revisions... according to our own rules, a schema change (which is needed to record a syntax) would require a major version bump
[15:28] <grahamtriggs> bearing in mind that we are not only already making a schema change in this release - we are already adding new columns to the metadatavalue table anyway
[15:28] <stuartlewis> So all you want is us to add 'alter table metadata_value add encoding varchar' to the db schema / upgrade in 1.6?
[15:29] <stuartlewis> Does anyone have any problems with making the db schema change?
[15:30] <kshepherd> i'm +1 on this change
[15:30] <mhwood> Adding a column should not cause any problems. +1
[15:30] <bollini> I'm thinking about the authority value...
[15:30] <jtrimble> +1
[15:30] <richardrodgers> No problem - but I am leery of changing without application support
[15:30] <bollini> +1 to add a column... but do we need an encoding column also for the authority value?
[15:31] <kshepherd> bollini: hmm, i'm not an expert on authority control, but as far as i know, the keys need to be plain strings so they can be used in GET requests, etc
[15:32] <grahamtriggs> richardrodgers: yes, it's partly related to the BMC stuff. According to SWAP documentation, I can only see the Context Object encoding as a supported way of passing some of the things requested. And besides, technically, it should be present anyway...
[15:32] <kshepherd> so it's probably ok to continue assuming that authority keys are plaintext strings
[15:32] <kshepherd> i might have missed something though
[15:33] <tdonohue> i'll admit, I'm still leery of DB changes without any connection to the application, but I think if others approve, it's fine
[15:34] <richardrodgers> grahamtriggs: no problem with Context objects per se or passing them, or parsing or storing them. The issue is whether we are just putting in a placeholder for a design later
[15:34] <tdonohue> (I just worry we could be "putting cart before the horse"...adding something that we *think* will work, without actually fully designing it out)
[15:34] <kshepherd> i can understand that concern.. but i also see this as a possible opportunity to show off what can be done with post-release overlays ;)
[15:35] <tdonohue> kshepherd: I definitely understand that...that's why I'm willing to back down on this, if others think it sounds like a good idea :)
[15:35] <stuartlewis> I suppose my opinion is based on "what;s next?". In the past we have crammed *lots* into 1.x.y releases, so if we are doing that again, then +1 to make the change now. If we are going to start developing 1.7 straight away, and only release 1.6.x to fix bugs, then I'd vote leave it for 1.7.
[15:35] <grahamtriggs> richardrodgers: if we store the context object, in the OpenURL syntax, then we need to mark that it is that syntax - otherwise it gets confused with the plain text citation, we can't handle it intelligently in the UI, we can't export it correctly with the indication that it is a kev:ctx, etc.
[15:36] <grahamtriggs> (here, the syntax is explicitly listed on the instance to distinguish it... http://www.ukoln.ac.uk/repositories/digirep/index/Scholarly_Works_Application_Profile#Bibliographic_Citation)
[15:37] <tdonohue> stuartlewis: I'd like to push for 1.7 right away (any volunteers to be release manager?)...but, I also know that development tends to slow down after major releases, as people work to upgrade locally, get comfortable with new features, etc.
[15:37] <richardrodgers> I would too, we've got several good features queued up....
[15:38] <tdonohue> that's good to know..."lined up features" can help make a quicker release path
[15:38] <mhwood> So are we sure of what SQL datatype we need for this new column? Are we going to need a "syntax registry" to make it intelligible through the UIs?
[15:38] <grahamtriggs> yes, I've got two separate project that I want to kick off in sandbox...
[15:39] <richardrodgers> grahamtriggs: I grant all these points. The question is that we won't have a mature design for 1.6 And later, when we do, we may need more columns, etc
[15:40] <grahamtriggs> richardrodgers: granted, but if we capture the OpenURL context object, and an encoding based on what we know now, we have the basis of being able to migrate it later. It's harder to mature the design, if we don't even get the basics in right first!
[15:41] <stuartlewis> grahamtriggs: What is your proposed timescale for making use of the new encoding column? 3m, 6m, 1y?
[15:41] <grahamtriggs> think about all those items people have got right now where they aren't capturing lots of useful metadata in a reliable machine parseable way
[15:41] <grahamtriggs> I'm anticipating that it will be used within a month or two
[15:42] <stuartlewis> How will it be used? By code in a 1.6.1?
[15:44] <grahamtriggs> give me a way to reliable store and identify OpenURL context objects, and I'll give you a reliable means to generate Endnote / RefMan / etc exports using context objects!
[15:44] <mhwood> The question is whether we can have the correct way by next week.
[15:45] <tdonohue> yea, i think we all agree these are good points and great ideas...it's just a matter of whether to rush this into 1.6...or work towards a quicker turnaround for 1.7
[15:45] <tdonohue> if we do have several features already lined up for a potential 1.7 -- we really could start branching almost immediately...and begin moving such features over in preparation, etc.
[15:46] <mhwood> That 1.7 should have a defined new-features list, to bound the time to release somewhat.
[15:46] <tdonohue> (err...not a "potential" 1.7...I mean "potential" features)
[15:47] <richardrodgers> For example, we have (1) rewritten Creative Commons (using web services), (2) Google citation metatags,
[15:47] <richardrodgers> (3) a curation management framework for virus checking, etc
[15:47] <grahamtriggs> tdonohue: depends on exactly what we are saying. I still favour the schema change now. Whether we push out a 1.6.1 that makes use of it, or just expect there to be patches offered (ie. for SWORD) that make use of it prior to a 1.7 as next release, is an open question...
[15:48] <tdonohue> to add to richardrodgers list: (4) we're working on export/import of Community/Collection hierarchy for better backups: http://jira.dspace.org/jira/browse/DS-466
[15:48] <stuartlewis> OK - let's go back to the decision. Shall we vote? Despite all my questions, I'd still be fine with it in 1.6.
[15:49] <tdonohue> sure, call a vote
[15:49] <mhwood> Do we know what the change is? Do we know it will be adequate?
[15:49] <bollini> I'm favour to the db change now... we have had for long time a mets column that was not used
[15:49] <bollini> +1
[15:49] <grahamtriggs> I want to change item_id on the metadatavalue table to resource_id, and add a resource_type... allowing proper metadata for communities, collection, bitstreams... maybe even hierarchical if we want to give metadata value a resource type...
[15:50] <stuartlewis> +1 (grahamtriggs can buy us all a beer if it ends up to not getting used / needs adjusting! :)
[15:50] <grahamtriggs> And yes, I have a really pressing reason for doing all of this, based on multilingual representations for communities and collections, which would also be fed back
[15:50] <tdonohue> grahamtriggs: is that for later? or is that part of this proposal
[15:50] <mhwood> Sounds like movement toward DSpace 2.
[15:51] <grahamtriggs> the item_id change is a sandbox effort for the 'next' dspace revision
[15:51] <tdonohue> ok, makes sense (just got confused of context)
[15:51] <caryn> by changing "item_id" to "resource_id", does that mean that you want to store metadata for items, communities, and collections in the metadata value table?
[15:52] <grahamtriggs> mhwood: I kind of agree. I would chuck in the overhaul of the bitstream registry that Larry left behind, and call it 2, not 1.7
[15:52] <grahamtriggs> caryn: yes.
[15:53] <tdonohue> I'm gonna recall this vote, with the full proposal here...this seems a bit sidetracked
[15:53] <stuartlewis> Anyone else going to vote? We're on +2 at the moment.
[15:53] <tdonohue> vote on Graham's proposal: Which is just to add an "encoding" column to the "metadatavalue" table to allow for machine readable values to be stored in any metadata fields.
[15:53] <caryn> k, does this mean we maintain the collection and community tables as well as metadata for communities and collections in the metadatavalue table? (sorry, just trying to get my mind around this)
[15:53] <tdonohue> we already have +2 from stuart and andrea
[15:54] <tdonohue> caryn: that comment was unrelated to graham's proposal. He was talking about possible additions for 1.7
[15:54] <caryn> ah, got it
[15:54] <grahamtriggs> the 'metadata' that exists on collection / community would be migrated. You still need to maintain the objects, but the values would move off into something extensible, flexible
[15:54] <tdonohue> any other votes? I'm going to vote 0 on this...still hesitant, but willing
[15:55] <mhwood> Add metadatavalue.encoding: 0
[15:55] <kshepherd> sorry, realised my earlier one might have been missed
[15:55] <kshepherd> add column to metdatavalue: +1
[15:55] <richardrodgers> I like the idea, and won't oppose it - just want to see it fleshed out, so: 0
[15:56] <kshepherd> (with the expectation of free beer if it doesn't work out ;))
[15:56] <caryn> 0 - potentially a useful addition, but not quite sure of all the implications
[15:56] <grahamtriggs> iirc, we had 3 +1 earlier - jtrimble, bollini, mhwood
[15:56] <jtrimble> For simple column add +1
[15:57] <tdonohue> ok...it looks like that means +4 total, with no one against
[15:57] <mhwood> Sorry, I changed my mind -- I haven't seen enough to convince me that more schema changes won't be needed.
[15:57] <mhwood> But I won't oppose.
[15:58] <tdonohue> ok..either way, since we have so many obstaining, I'd like to recommend posting a Jira proposal for a few days. Assuming no one is vehemently against this, it can be added to trunk
[15:58] <stuartlewis> Sounds good to me.
[15:58] <tdonohue> (the only reason I say this is it's a very close vote, and we have a few people not in attendance today)
[15:58] <stuartlewis> In which case, when do we look at cutting a 1.6 rc2?
[15:58] <stuartlewis> As soon as that, spiders.txt, and jspui i18n is in svn?
[15:59] <tdonohue> it sounds like 1.6 RC2 needs to be next week, since we are waiting on those two issues in Jira as well
[15:59] <grahamtriggs> which two issues?
[15:59] <stuartlewis> But presumably we can do it as soon as those are in. E.g. no need to wait for a set day, just as soon as the commits have been made.
[16:00] <stuartlewis> grahamtriggs: spiders.txt being empty, and jspui i18n being broken
[16:00] <tdonohue> grahamtriggs: we are waiting on http://jira.dspace.org/jira/browse/DS-418 and http://jira.dspace.org/jira/browse/DS-440
[16:00] <mhwood> Feature freeze after these three?
[16:00] <jtrimble> I'll plan to be done with all documentation on Monday morning. I'll compile the final html and PDF the night before the rc2 is cut
[16:00] <stuartlewis> Yes - we're in feature freeze already
[16:00] <grahamtriggs> ah ok, it was just when you said 'as well'
[16:01] <mhwood> But we're adding features?
[16:01] <stuartlewis> Yes.
[16:01] <grahamtriggs> mhwood: yes, but it's bloody freezing here, so that's ok
[16:01] <tdonohue> One last topic I want to bring up: http://jira.dspace.org/jira/browse/DS-470 it's had a ton of discussion recently
[16:01] <stuartlewis> To clarify: As soon as spiders.txt is populated, the jspui i18n issue is fixed, and Graham's schema changes are made, we'll cut 1.6rc2.
[16:02] <stuartlewis> DS-470: Look at in 1.6.1
[16:02] <grahamtriggs> ahh..... DS-470.........
[16:02] <tdonohue> I'm not sure if this is something we want to respond to in some way (or at least schedule for a release)
[16:02] <stuartlewis> Depends on how much of an API change we want to make. Might need pushing to 1.7.
[16:03] <grahamtriggs> the patch makes some fundamentally wrong decisions, regardless of whether we see this as something really worth addressing which in itself could be debatable
[16:03] * jtrimble (n=jtrimble@maag127.maag.ysu.edu) Quit ("Leaving")
[16:04] <tdonohue> ok, so the only thing I'd point out is the patch is *tiny* and it makes a huge benefit in import speed. But, if we all agree it really just needs more analysis, then we can delay for 1.6.1 or 1.7
[16:04] <stuartlewis> I'm not sure it needs any formal response, as there is lots of debate about it still going on.
[16:04] <richardrodgers> I want to do some analysis and benchmarking of the problem, and I agree with many of grahamtriggs concerns about the code
[16:04] <tdonohue> ok, sounds good
[16:04] <mhwood> Agreed, needs more thought.
[16:04] <stuartlewis> And the patch is there, so if anyone is suffering because of this problem, they at least have a fix.
[16:05] <richardrodgers> exactly
[16:05] <grahamtriggs> I haven't even addressed all my issues yet... I took a look at the patch properly for the first time tonight. I have more to add!
[16:05] <tdonohue> I just wanted to post some sort of comment that we are looking at it (since it's been discussed a lot). I'll add a comment that we discussed this and that we all feel it may need more analysis for a potential fix in 1.6.1 or 1.7
[16:05] <stuartlewis> tdonohue: +1 sounds good
[16:06] <mhwood> This goes pretty deeply into what DSpace is for, so we want to take enough time to get it really right.
[16:06] <richardrodgers> tdonohue: +1 - I do really value Cambridge's close look at scaling
[16:06] <tdonohue> that's everything I had on the agenda. I'm serious about the call for a 1.7 release manager -- if anyone has an interest let me know. Is there anything else to discuss?
[16:08] <tdonohue> Ok..sounds like we are done here. Thanks for the discussion. I'm excited to see 1.6RC2 cut soon (hopefully early next week)
[16:08] <kshepherd> cheers all
[16:08] <mhwood> Thanks, all!
[16:08] <bollini> bye all
[16:08] * bollini (n=chatzill@host102-175-dynamic.17-87-r.retail.telecomitalia.it) Quit ("ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]")
[16:08] <richardrodgers> bye, thanks all
[16:08] * richardrodgers (n=richardr@dhcp-18-111-11-204.dyn.mit.edu) Quit ()
[16:09] * caryn (i=80c8e115@gateway/web/freenode/x-pxujsfhxtjretchz) Quit ("Page closed")
[17:21] * keithg (n=keith-no@lib-kgilbertson.library.gatech.edu) Quit ()
[17:23] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[18:09] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[19:48] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit ()
[23:16] * awoods (n=awoods@pool-72-66-126-180.washdc.fios.verizon.net) Quit (Read error: 110 (Connection timed out))
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.