#duraspace IRC Log


IRC Log for 2010-04-21

Timestamps are in GMT/BST.

[0:16] * stuartlewis (~stuartlew@ has joined #duraspace
[0:27] * stuartlewis (~stuartlew@ Quit (Read error: Connection reset by peer)
[0:29] * stuartlewis (~stuartlew@ has joined #duraspace
[1:02] * stuartlewis (~stuartlew@ Quit (Quit: stuartlewis)
[1:40] * stuartlewis (~stuartlew@ has joined #duraspace
[1:46] * stuartlewis (~stuartlew@ Quit (Quit: stuartlewis)
[2:34] * stuartlewis (~stuartlew@ has joined #duraspace
[3:05] * stuartlewis (~stuartlew@ Quit (Quit: stuartlewis)
[3:11] * stuartlewis (~stuartlew@ has joined #duraspace
[4:08] -hubbard.freenode.net- *** Looking up your hostname...
[4:08] -hubbard.freenode.net- *** Checking Ident
[4:08] -hubbard.freenode.net- *** Found your hostname
[4:08] -hubbard.freenode.net- *** No Ident response
[4:08] [frigg VERSION]
[4:08] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:08] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:08] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[5:59] * stuartlewis (~stuartlew@ Quit (Quit: stuartlewis)
[6:03] * Xpath (Xpath@server2003.esa.ipb.pt) Quit ()
[8:10] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[8:58] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:20] * ksclarke (~kevin@ has joined #duraspace
[13:12] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:07] * arcmaster (~arcmaster@cm5.psi155.maxonline.com.sg) has joined #duraspace
[14:08] * arcmaster (~arcmaster@cm5.psi155.maxonline.com.sg) has left #duraspace
[14:16] * tdonohue is now known as duraspace|tdonoh
[14:43] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[14:50] * duraspace|tdonoh is now known as DuraSpace|TimD
[14:54] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[15:04] * stuartlewis (~stuartlew@ has joined #duraspace
[15:12] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:12] * ksclarke (~kevin@ Quit (Ping timeout: 252 seconds)
[15:16] * stuartlewis (~stuartlew@ Quit (Quit: stuartlewis)
[15:30] * ksclarke (~kevin@ has joined #duraspace
[15:52] * robint (~52292565@gateway/web/freenode/x-tndmtaczdzshnpva) has joined #duraspace
[15:55] * carynn (~cneiswen@c726.staff.lib.uci.edu) has joined #duraspace
[15:56] * cccharles (~cccharles@ has joined #duraspace
[15:57] <DuraSpace|TimD> Hi all...DSpace Developers Meeting here in a few minutes. Agenda up at: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-04-21
[15:58] <DuraSpace|TimD> FYI -- I'm also in a GSoC meeting (hence my weird nickname -- DuraSpace|TimD) that is running long. Gonna try and multitask here as best I can
[16:00] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[16:01] <DuraSpace|TimD> Ok all..might as well get started. Again, agenda at: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-04-21
[16:01] <DuraSpace|TimD> I'm also in a GSoC IRC meeting right now (to make final project decisions and deduplicate), so hopefully I don't get pulled away suddenly :)
[16:02] <DuraSpace|TimD> First off...I'm out of office next week, and may not be able to make it to next week's meeting. Any volunteers to lead the meeting on my behalf?
[16:03] * DuraSpace|TimD and then there was silence
[16:03] <PeterDietz> Would someone be able to come up with an agenda, or is that also the job of the meeting leader
[16:04] <DuraSpace|TimD> I already mapped out an agenda on today's agenda :)
[16:04] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has joined #duraspace
[16:04] <DuraSpace|TimD> next week's general agenda would be: 1.6.1 updates, GSoC project announcements, and JIRA review -- we just need a volunteer to lead discussion as I'll be out
[16:05] <PeterDietz> I can do the meeting leading next week
[16:06] <DuraSpace|TimD> thanks PeterDietz. Mostly it's just keeping discussion moving along...kshepherd is the contact for 1.6.1 updates, and mdiggory could give updates on GSoC for the meeting (yea, I'm volunteering you two for next week)
[16:07] <mdiggory> ok, sounds ok atm
[16:07] <grahamtriggs> Speaking of keeping things moving... according to agenda, GSoC update first.... should be fun watching Tim juggle between two meetings on the same subject :)
[16:08] <DuraSpace|TimD> ok...moving along. Latest on GSoC is that it looks like we will have 4 great projects this year. Unfortunately, we still are not able to make them public until Google announces everything on the 26th. So, next week
[16:08] <DuraSpace|TimD> so, next week will be official announcement of projects
[16:08] <DuraSpace|TimD> also, an FYI to the GSoC mentors out there -- I gave back our extra project slot (we were originally given 5, but decided to use just 4)
[16:10] <DuraSpace|TimD> Ok, next on agenda...DuraSpace would like to upgrade DSpace's Jira to 4.x (from 3.x), and also investigate merging it into a single DuraSpace JIRA (shared with Fedora). More on agenda: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-04-21
[16:10] <DuraSpace|TimD> Does anyone have any general concerns on this? I already had some +1 votes (Stuart & mdiggory) in #dspace earlier today
[16:10] <grahamtriggs> +1
[16:11] <mhwood> +1
[16:11] <richardrodgers> fine with me +1
[16:11] <PeterDietz> +1
[16:12] <DuraSpace|TimD> Ok...sounds like that's a general consensus. I'm all in favor of it, as JIRA 4.x is miles better than 3.x...and doing this will let us share the same login/pwd between JIRA and our Wiki
[16:12] <grahamtriggs> would we be upgrading one (or both) instances and then folding one into the other? Or establishing a new one with proposed layouts and migrating existing instances into it?
[16:12] <DuraSpace|TimD> grahamtriggs: unsure yet...I'll be talking with Brad & Chris Wilper more about this next week, and we'll start to work on a plan
[16:13] <keithg> +1
[16:13] <DuraSpace|TimD> but, I'll let everyone know *how* it will happen once we figure it out
[16:14] <DuraSpace|TimD> Ok...I think it's time for a 1.6.1 update. kshepherd, you around?
[16:16] <DuraSpace|TimD> ok..sounds like he's not around right now.
[16:16] <DuraSpace|TimD> Well, I know we still have 24 open 1.6.1 issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10020&fixfor=10030
[16:17] <DuraSpace|TimD> Some are assigned, and some are not. If you have one assigned, please work with kshepherd to get it into 1.6.1 (or rescheduled if it won't be ready). If you have time, pick up one that is unassigned
[16:18] <PeterDietz> sorry to but in, but for the time being... I need to i18n "unknown country" whats the step to create a new entry in i18n, just do it? then tell claudia that languages need to add a field? or perhaps use a symbol like "- -" that needs no i18n
[16:18] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
[16:18] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[16:19] <DuraSpace|TimD> PeterDietz: for missing i18n, I'd say add it in, and notify Claudia.
[16:21] <mhwood> Anybody had time to look over DS-494? "DatabaseManager.process() unnecessarily limits range of DECIMAL or NUMERIC"
[16:21] <DuraSpace|TimD> mhwood: you looking for feedback on the patch for DS-494?
[16:22] <mhwood> Yes, please.
[16:22] <richardrodgers> mhwood: are we hitting any walls with respect to the size, or likely to?
[16:23] <mhwood> I am. There's another item that (among other things) gets the DBMS to total up the sizes of all bitstreams, and if you have a repo. bigger than 4GB it fails without 494.
[16:23] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[16:24] <mhwood> I'm not aware of any such overflows in the stock code.
[16:24] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:24] <mhwood> Woops, 2GB.
[16:26] <richardrodgers> 2GB is pretty modest, so that suggests we fix it....
[16:26] <PeterDietz> 2gb assetstore, or 2gb database?
[16:26] <DuraSpace|TimD> yea, it looks like a simple enough fix too..
[16:26] * DuraSpace|TimD is now known as tdonohue
[16:27] <mhwood> Assetstore. I'm just having the DBMS return sum(bitstream size)
[16:27] <PeterDietz> ohh ok, our assetstore is 40GB+, I guess I've never attempted sum(bs)
[16:28] <tdonohue> oh, now I understand. ok -- so , it's your custom stats code that has brought this to light
[16:28] <mhwood> Yes.
[16:28] <kshepherd> hi all, sorry i'm late
[16:29] <richardrodgers> SO the question becomes, it is risky for 1.6.1?
[16:29] * sandsfish (~sandsfish@dhcp-18-111-28-123.dyn.mit.edu) has joined #duraspace
[16:29] <PeterDietz> ...and that about wraps it up. good meeting
[16:29] <PeterDietz> jk
[16:29] <tdonohue> hi kshepherd. we were still on topic of 1.6.1 -- so, once you get situated, we could do some more 1.6.1 updates.
[16:30] <mdiggory> Hi guys sorry, distractions
[16:30] <kshepherd> ok
[16:30] <tdonohue> richardrodgers: that is a good question. Is DS-494 an issue that may need to go into further testing (like a full testathon sequence) -- if so, it may be best for 1.7.0
[16:30] <mhwood> Exactly. I haven't modified the database layer before and was hoping that more experienced eyes would be able to check for obvious blunders.
[16:31] <tdonohue> mhwood -- at a quick glance, it seems "safe" -- but, I'll admit, we might want to leave for a full testathon + 1.7.0, just in case (as it doesn't seem to cause issues in out-of-the-box dspace)
[16:32] <mdiggory> I think that if it is backward compatible, there is no reason not to do it in 1.6.x
[16:33] <mdiggory> If there is a concern that it will cause problems, you could make it an option that is disabled by default
[16:33] <mdiggory> and make it enabled by default in 1.7
[16:34] <richardrodgers> mhwood: Ill try to look at the patch soon & give you feedback
[16:34] <mhwood> richardrodgers: Thanks!
[16:34] <kshepherd> 1.6.1 update: we seem to be on track.. not a great deal of code committed yet, but i'm sitting on a few patches that are just waiting for a bit more testing, as other others, so it'd be awesome to get some of these tested/reviewed further so they can be committed over the next week
[16:34] <tdonohue> yea..if any others can look more closely & test it -- then I'm all for keeping it scheduled for 1.6.1 -- we just need more eyes
[16:35] <tdonohue> kshepherd: do you have a list of issues that are waiting for further review? Maybe we could post those somewhere to get more eyes on them?
[16:36] <kshepherd> yep great idea
[16:36] <kshepherd> you carry on, i'll get the list together
[16:36] * jtrimble (~jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[16:36] <tdonohue> ok...sounds great, kshepherd. we may want to post generally to dspace-devel or wiki, for anyone unable to make this meeting
[16:37] <tdonohue> Any other items to bring up? Or should we jump into another JIRA review (to try and catchup again)?
[16:37] <mdiggory> Per Embargos, just fielded a call concerning some difficulties setting it up and referencing this thread
[16:37] <mdiggory> http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg10350.html
[16:38] <richardrodgers> Hasn't that been addressed?
[16:38] <kshepherd> what was the problem?
[16:38] <mdiggory> Sounds like this minor change got in. But are there any other major issues with embargo that others have been experiencing
[16:39] <tdonohue> what issues have you heard of?
[16:39] <kshepherd> i've been working with embargo framework a lot lately, i'm not having any major issues
[16:40] <mdiggory> CSU was doing upgrades to 1.6.0 and having issues becuase they had started out using the JHU embargo solution
[16:40] <kshepherd> oh
[16:40] <kshepherd> well.. they're very different approaches
[16:40] <tdonohue> oh...so it's migrating from an old embargo solution to a new one?
[16:40] <richardrodgers> It's not backward compatible with all the prior approaches
[16:40] <kshepherd> JHU is database-driven and collection-driven
[16:40] <mdiggory> The most significant complaint was a lack of documentation on configuring embargos.
[16:41] <mdiggory> very true
[16:41] <kshepherd> if anyone's interested, i did hack dspace search/browse to make embargoed items undiscoverable, and it seems to be working pretty well
[16:41] <tdonohue> Yea, I noticed our docs don't even detail that you need to add embargo fields to input-forms.xml (unless i missed that)
[16:41] <jtrimble> um--they don't
[16:42] <jtrimble> embargo documentation was scant from the get go.
[16:42] <mdiggory> If we could start to organize activities int he WIKI a bit better, we could see content like this turn into documentation
[16:42] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/Embargo+1.6
[16:42] <tdonohue> so, maybe we need at least a JIRA issue to better document *how* to setup embargos
[16:42] <mdiggory> this page is now out of date, it was great when the project started, but now may actually be misleading
[16:42] <tdonohue> yea...that wiki page is really out-of-date now
[16:43] <jtrimble> Sorry to stop and go, I've got McAfee virus issues today..so my time is wacked out. I'll be in next wedneday for ths meeting.
[16:43] * jtrimble (~jtrimble@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[16:43] <tdonohue> So, mdiggory have you added a JIRA issue for Embargo documentation? Maybe we should get that in, minimally, and add to 1.6.1
[16:43] <mdiggory> Overall, if we had a editorial process that took existing wiki pages and targeted them for inclusion into documentation removing them / migrating them to the planned documentation confluence space (if we go that route)
[16:44] <mdiggory> If we had this as a process, then we would end up with less stale content in the wiki and more documentation
[16:44] <mdiggory> And less need for the documentation to be in the svn repository...
[16:45] <mhwood> Yes! A wiki is a great way to gather lots of knowledge, but some items need to be edited and incorporated into more structured documents.
[16:45] <mdiggory> because it would all be maintained online by those who need it to be accurate
[16:45] <mdiggory> you can use confluence to manage editorail rights/control on documents
[16:46] <tdonohue> mdiggory: sounds reasonably logical, but, it'd be good to get those ideas up on the Wiki somewhere (maybe as a proposal), so that others (jtrimble especially) can comment, and we can figure out a workflow that will work well for all
[16:46] <mdiggory> And jtrimble and I have talked about this.
[16:47] <mhwood> OTOH /me thinks converting the nice Docbook sources into wiki goo is a step backward.
[16:47] <tdonohue> I think in concept this sounds great. Just would like to better understand the editorial "workflow" you are proposing, etc
[16:47] <mdiggory> I agree that it needs to happen, but we are all short on time... What Jeff and I talked about last was updating the docs that are in confluence atm to reflect the changes that went into the SVN for 1.6.0
[16:47] <mdiggory> mhwood: of course I totally disagree
[16:47] <mdiggory> politely
[16:48] * tdonohue notices we likely are not going to have time for JIRA review today -- PeterDietz, this could be a main agenda item for next week
[16:48] <mhwood> Understood. Where the doco. lives and how we gather it are two different questions.
[16:49] <mdiggory> Yes, there should be a copy distributed with all releases that is accurate to that release
[16:49] <tdonohue> I'll admit, I'd also like to see the docs out of docbook in SVN (if we can come up with a solution that works for all), so that we don't have to funnel most/all changes through jtrimble (which makes his role difficult)
[16:49] <mdiggory> And maybe that can be a pdf updated periodically by and export we generate using confluence
[16:50] <mdiggory> all of which has been proven possible
[16:50] <mdiggory> tdonohue: agreed
[16:50] <tdonohue> mdiggory: is your previous work on this publicly available?
[16:50] <kshepherd> if no JIRA review, can i just paste a short list of recent patches that could do with review/testing before commit?
[16:51] <mdiggory> http://fedora-commons.org/confluence/display/DSTEST/Home
[16:51] <tdonohue> kshepherd, go for it...(unfortunately I have to leave right at 21:00UTC today -- but, if others have time to help you review now or offline later, I'd encourage it)
[16:51] <kshepherd> i'm due in a meeting in about now anyway, i don't have time to talk about them too much
[16:52] <kshepherd> but here they are, in case anybody has time to check them out and comment/advise:
[16:52] <kshepherd> http://jira.dspace.org/jira/browse/DS-497
[16:52] <kshepherd> http://jira.dspace.org/jira/browse/DS-509
[16:52] <kshepherd> http://jira.dspace.org/jira/browse/DS-527
[16:52] <kshepherd> http://jira.dspace.org/jira/browse/DS-542
[16:52] <kshepherd> http://jira.dspace.org/jira/browse/DS-547
[16:52] <tdonohue> mdiggory: thanks, that is a good example of the pre-1.6.0 docs in Confluence
[16:52] <kshepherd> http://jira.dspace.org/jira/browse/DS-548
[16:53] <mdiggory> This was based somewhat on what Fedora has been doing
[16:53] <mdiggory> http://fedora-commons.org/confluence/display/FCR30/Fedora+Repository+3.3+Documentation
[16:53] <tdonohue> Thanks, kshepherd! Hopefully a few folks can be more helpful than I today (I'm rushing off to holiday almost immediately after this, can you tell?)
[16:53] <kshepherd> heh
[16:54] <mdiggory> tdonohue: don't rub it in
[16:54] <tdonohue> haha...not trying too, but I am counting down the minutes -- let's see, 5 left
[16:55] <tdonohue> but, seriously, those docs in Confluence look nice to me. But, it'd be worth coming up with a nice editorial workflow, so that not everyone (i.e. general public) can just edit those primary docs -- they would need to be restricted to commiters (and other trusted folks)
[16:56] <mdiggory> This is one of the benefits of using a separate space
[16:56] <mdiggory> we can control access separately from the main wiki
[16:56] <tdonohue> yep. understood
[16:56] <mdiggory> and likewise, using confluence, we can move pages between spaces easily
[16:57] <tdonohue> are you and jtrimble working on updating that space with the absolute latest 1.6.0 docs?
[16:57] <mdiggory> We've talked about it... but not planned anything
[16:57] <tdonohue> cause, at some point, we really need to bring this to an official "vote" to be sure we are all in agreement to this strategy
[16:58] <mdiggory> So, I'd rather not work on it and then have it voted down.
[16:59] <mdiggory> updating the existing content shouldn't take very long.
[16:59] <tdonohue> agreed. I'll add this to a future agenda. We should prepare folks to discuss this first (by sending them the links to your work, etc.), and then hopefully bring it to a vote
[16:59] <tdonohue> OK. any last words? comments? Otherwise, I'm ready to close the meeting
[17:00] <richardrodgers> have a good vacation tdonohue !
[17:00] <kshepherd> ok i really need to go now.. i'll send out an email with more of an update for 1.6.1
[17:00] <mdiggory> great sounds like a good strategy, I can look into updating to at least what is in the trunk
[17:00] <tdonohue> thanks kshepherd
[17:01] <tdonohue> thanks all! meeting closed...have a good one, and I'll talk to you all in a few weeks
[17:01] <mhwood> Enjoy! 'bye, everybody.
[17:01] * sandsfish (~sandsfish@dhcp-18-111-28-123.dyn.mit.edu) Quit (Quit: sandsfish)
[17:03] <keithg> have a nice holiday!
[17:03] <richardrodgers> bye all
[17:03] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has left #duraspace
[17:04] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[17:07] * ksclarke (~kevin@ Quit (Quit: Leaving.)
[17:08] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithg)
[17:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:12] * carynn (~cneiswen@c726.staff.lib.uci.edu) has left #duraspace
[17:17] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[17:17] * robint (~52292565@gateway/web/freenode/x-tndmtaczdzshnpva) Quit (Ping timeout: 248 seconds)
[17:30] * GavinH (~GavinH@86-44-84-117-dynamic.b-ras2.bbh.dublin.eircom.net) has joined #duraspace
[17:30] <GavinH> Evening.
[17:54] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[17:55] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[18:58] * Xpath (Xpath@ has joined #duraspace
[18:59] <Xpath> who please send me a zip mets example?
[19:11] * mdiggory (~mdiggory@ has joined #duraspace
[19:20] * Xpath (Xpath@ Quit ()
[19:24] * ksclarke (~kevin@ has joined #duraspace
[20:25] * stuartlewis (~stuartlew@ has joined #duraspace
[20:26] <GavinH> boo
[20:31] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[20:36] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:42] * GavinH (~GavinH@86-44-84-117-dynamic.b-ras2.bbh.dublin.eircom.net) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!)
[20:43] * mdiggory (~mdiggory@ Quit (Quit: mdiggory)
[20:56] * mdiggory (~mdiggory@ has joined #duraspace
[21:19] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[21:20] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:36] * mdiggory (~mdiggory@ Quit (Quit: mdiggory)
[21:51] * mdiggory (~mdiggory@ has joined #duraspace
[22:45] * stuartlewis (~stuartlew@ Quit (Quit: stuartlewis)
[23:14] * mdiggory (~mdiggory@ Quit (Quit: mdiggory)
[23:20] * awoods (~awoods@pool-173-73-6-67.washdc.fios.verizon.net) Quit (Ping timeout: 265 seconds)
[23:32] * ksclarke (~kevin@ Quit (Quit: Leaving.)

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.