Timestamps are in GMT/BST.
[3:01] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[3:38] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[5:24] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) Quit (Quit: Leaving.)
[6:31] -niven.freenode.net- *** Looking up your hostname...
[6:31] -niven.freenode.net- *** Checking Ident
[6:31] -niven.freenode.net- *** Found your hostname
[6:31] -niven.freenode.net- *** No Ident response
[6:31] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:31] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:31] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:03] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[7:12] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Ping timeout: 260 seconds)
[7:24] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[10:34] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[11:56] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (Quit: alxp)
[12:20] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[13:09] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:32] * bradmc_ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:32] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[13:32] * bradmc_ is now known as bradmc
[14:22] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:26] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) has joined #duraspace
[15:26] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:28] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:33] * scottatm (~scottatm@adhcp208.evans.tamu.edu) Quit (Read error: Connection reset by peer)
[15:34] * scottatm (~scottatm@adhcp208.evans.tamu.edu) has joined #duraspace
[16:20] * scottatm (~scottatm@adhcp208.evans.tamu.edu) Quit (Read error: Connection reset by peer)
[16:21] * scottatm (~scottatm@adhcp208.evans.tamu.edu) has joined #duraspace
[16:25] * scottatm (~scottatm@adhcp208.evans.tamu.edu) Quit (Read error: Connection reset by peer)
[16:28] * scottatm (~scottatm@adhcp208.evans.tamu.edu) has joined #duraspace
[16:28] * scottatm (~scottatm@adhcp208.evans.tamu.edu) Quit (Client Quit)
[16:32] * 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:33] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:45] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Operation timed out)
[16:45] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:46] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (Read error: Operation timed out)
[16:46] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[17:13] * Ashan (~Ashan@202.129.235.30) has joined #duraspace
[17:17] * Ashan (~Ashan@202.129.235.30) Quit (Ping timeout: 246 seconds)
[17:30] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[17:31] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[18:12] * Mayank1 (~beakkon@122.162.139.179) has joined #duraspace
[18:30] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[18:32] * Mayank1 is now known as Mayank
[19:16] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Read error: Connection reset by peer)
[19:26] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:32] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Ping timeout: 272 seconds)
[19:41] * mobile (~mobile@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:41] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[19:45] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:51] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:57] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:57] * ElinS (56097ad4@gateway/web/freenode/ip.86.9.122.212) has joined #duraspace
[19:58] <tdonohue> Hey all -- DSpace Developers mtg starts here in a few minutes. Today's agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-23
[19:59] * KevinAtmire (KevinAtmir@94-227-62-14.access.telenet.be) has joined #duraspace
[20:00] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[20:00] * KevinAtmire is now known as Kevin_Van_de_Vel
[20:00] <tdonohue> Ok all..may as well get started with our meeting today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-23
[20:01] * Kevin_Van_de_Vel is now known as Kevin_VdV
[20:02] * kshepherd is on time today, for once
[20:02] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:02] <tdonohue> First off...I hope our friends in New Zealand (stuartlewis & kshepherd) are doing fine after the recent earthquake. Hopefully your friends/family are all ok.
[20:02] <kshepherd> thanks tdonohue. it's all a bit horrible.
[20:02] <tdonohue> yea, I can tell from all the news...
[20:02] <kshepherd> still waiting to hear from a few friends but it's most likely that they are just still out of power (most of the city has no power/water)
[20:02] <stuartlewis> (and snail - he's another local)
[20:03] <tdonohue> oh, yes, and snail as well. Thanks for the reminder
[20:03] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) has joined #duraspace
[20:03] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:03] <snail> I'm here, but busy right now updating status of chch public libraries
[20:03] <mhwood> Yeah, I thought of you all too. The pictures look scary.
[20:04] <tdonohue> so, we probably should go ahead and get started here...I'd like to kick things off with JIRA review as usual. But, I'd like to do a "quick review" version (which we used to do over a year ago). Our JIRA backlog is getting a bit large, so we should work to catch up
[20:05] <stuartlewis> 60 seconds each?
[20:05] <tdonohue> we'll do 2 mins per issue this time around...just to get back into it. Please do a quick analysis, and vote +1 (keep issue, seems important), -1 (close immediately), 0 (unsure)
[20:06] <tdonohue> If you are willing to look into it more, please volunteer
[20:06] <tdonohue> Ok...we'll get started, as soon as I get the first issue loaded up
[20:06] <tdonohue> https://jira.duraspace.org/browse/DS-682 : The Select Collection step performs badly with a large number of collections.
[20:06] <stuartlewis> Did you want someone to do the loading, or the counting for each?
[20:07] <tdonohue> stuartlewis -- i can load up next issue, if you would be willing to count votes :)
[20:07] <stuartlewis> tdonohue: OK.
[20:07] <PeterDietz> I have a patch: https://gist.github.com/830334
[20:07] <kshepherd> DS-682 - PeterDietz has definitely been looking into this, though there are no comments from him in JIRA yet
[20:07] <kshepherd> oh, snap :)
[20:07] <tdonohue> Excellent...PeterDietz, can we assign to you then?
[20:07] <PeterDietz> still a little work to do, see comment, //check eperson->comm-admin
[20:07] <stuartlewis> +1 then :)
[20:08] <PeterDietz> yeah sure, tdonohue I'll take it
[20:08] <tdonohue> +1 -- assign to PeterDietz
[20:08] <kshepherd> +1
[20:08] <mhwood> +1 solution in progress
[20:08] <PeterDietz> If I spent half as much time working on things as I do talking about them, it would be done a month ago ;)
[20:08] <stuartlewis> Any other votes? If not, +4 and assign to P eterDietz
[20:08] <tdonohue> Next one -- https://jira.duraspace.org/browse/DS-683 : Incorporate Security / Quality recommendations from AppScan report
[20:09] <tdonohue> Oh, wait..is this just a placeholder, PeterDietz?
[20:09] <tdonohue> DS-683, that is
[20:09] <PeterDietz> just a place holder perhaps.. something more than just an email that we never responded to
[20:09] <kshepherd> it has links to other issues
[20:09] <kshepherd> which are more specific in terms of changes to be made
[20:10] <tdonohue> skipping DS-683 -- one of it's links is resolved, and the other one is the next issue to review :)
[20:10] <stuartlewis> 684 is presmably a duplicate of the old 'what to do with bad browse requests' issue?
[20:10] <tdonohue> https://jira.duraspace.org/browse/DS-685 : Remove sensitive information from HTML comments
[20:10] <stuartlewis> Ah - already closed as a dupe :)
[20:10] <kshepherd> and DS-640 is assigned to me
[20:11] <kshepherd> which i will fix for 1.7.1, with the caveat that cocoon still doesn't do 404s properly
[20:11] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:11] <mhwood> DS-685: +1
[20:12] <tdonohue> DS-685: +1 to fix
[20:12] <kshepherd> +1 to DS-685 -- but again note that people may still be able to expose this via /DRI/... or ?XML
[20:12] <stuartlewis> +1
[20:13] <tdonohue> (agree with kshepherd -- this is useful in XMLUI development -- so, there needs to be a way to enable it again as needed)
[20:13] <stuartlewis> Any other votes? If not, +4, no assignee
[20:13] <tdonohue> https://jira.duraspace.org/browse/DS-690 : Tidy up URL mapping for DisplayStatisticsServlet (JSPUI servlet that handles solr statistics)
[20:13] <kshepherd> in early xmlui days, the /metadata/handle/*/*/mets.xml files were restricted to localhost
[20:13] <kshepherd> that was removed for opensearch or openurl or opensomething
[20:14] <kshepherd> DS-690 is mine
[20:14] <tdonohue> +1 to DS-690
[20:14] <kshepherd> would appreciate any pointers or criticisms in comment thread
[20:14] <kshepherd> because it's not as straightforward as it first appeared
[20:14] <kshepherd> i think i have to use HandleServlet, which i was initially trying to avoid
[20:15] <tdonohue> aha -- i see. Yea, this is harder in JSPUI...a lot of old JSPUI URLs end up with ?querystring, because of this same issue
[20:15] <PeterDietz> it would be nice to rename the varying version of statistics... legacy vs solr vs minho
[20:16] <tdonohue> I'm going to change my vote on DS-690 to a '0'. I'm not sure this is really an important issue? There's not a real parity between other JSPUI/XMLUI URL paths...
[20:16] <stuartlewis> 0 for me too - but I don't see harm in fixing it.
[20:16] <mhwood> 0
[20:16] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[20:17] <kshepherd> ok, i'll prioritise lower than my other issues
[20:17] <stuartlewis> Any other votes? If not, +1 / 3x0
[20:17] <tdonohue> https://jira.duraspace.org/browse/DS-692 : Clean up invalid HTML in collection and community metadata
[20:18] <stuartlewis> Could this be implemented as a curation task?
[20:18] <richardrodgers> So this is a migration tool?
[20:18] <tdonohue> +1 to stuartlewis's question. Seems like a potential curation task?
[20:18] <PeterDietz> this is a 1.6-era thing, so a likely candidate for implementation as curation task
[20:19] <PeterDietz> yeah, this was essentially a one-time thing. convert <br> to <br/> and such
[20:19] <mhwood> And people will continue to put invalid HTML in, so it's not really migration-only.
[20:19] <richardrodgers> OK, then if the latter, I agree it looks curation task-like..
[20:19] <tdonohue> +1 if this is made into a curation task
[20:20] <kshepherd> +1 to curation task with reporting/noop and 'fix' options
[20:20] <PeterDietz> adding some client-side input validation on edit item/collection/community would help stop users from doing bad things
[20:20] <mhwood> +1
[20:20] <stuartlewis> +1
[20:20] <PeterDietz> I'm fine with curation-task-ifying it
[20:20] <stuartlewis> Any other votes? If not, +4, keep assigned to PeterDietz
[20:20] <tdonohue> https://jira.duraspace.org/browse/DS-700 : Bulk Metadata Editing: defining "formats" for export/re-import of selected fields
[20:21] <tdonohue> DS-700: 0 -- not sure I fully understand at a glance
[20:22] <mhwood> 0 what he said.
[20:22] <kshepherd> stuartlewis has done a bit of this sorta stuff already
[20:22] <kshepherd> unless i read it wrong
[20:22] <tdonohue> so, is this "obsolete"?
[20:22] <stuartlewis> Yes - I'm probably going to look into this in the next few months.
[20:22] <kshepherd> no, not obselete
[20:23] <stuartlewis> Allows you define profiles for the CSV downloads to suit different purposes.
[20:23] <kshepherd> first, i requested the ability to only export certain fields. then, it became clear that we needed different 'profiles' to select an export from
[20:23] <stuartlewis> +1, assign to me
[20:23] <kshepherd> and Christophe's 'template csv' idea seems good
[20:23] <kshepherd> +1
[20:23] <richardrodgers> btw stuartlewis : if you haven't looked at Google Refine as an editor for the CSV data, do
[20:23] <tdonohue> ok...makes sense then. assign to stuartlewis
[20:23] * sandsfish (~sandsfish@18.111.30.208) has joined #duraspace
[20:23] <stuartlewis> Yes - had a good play with that when it was called GridWorks - love it! :)
[20:24] <kshepherd> yes, refine++
[20:24] <stuartlewis> Any other votes? If not, +2, assign to stuartlewis
[20:24] <sandsfish> hi all, sorry to jump in half-way.
[20:24] <tdonohue> we'll stop there for today. Thanks all! we made it through 6 JIRA issues today (last few weeks it's only been around 2-3)
[20:24] * mobile (~mobile@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Colloquy for iPhone - http://colloquy.mobi)
[20:25] <tdonohue> so, I'd like to continue in the coming weeks with this "quick review" format... I really want to get us caught up on our backlog of issues
[20:25] <mhwood> Though I would like to talk and talk about some of them, I think this way is better.
[20:26] <tdonohue> yea, I agree mhwood. And we can always schedule some for 'deeper discussion', if we deem necessary
[20:26] <kshepherd> can always use JIRA comments for longer discussion ;)
[20:26] <tdonohue> Ok. I'd like to now spend some time (5-10 minutes) discussing the next JIRA Feature Request review from the DCAT Team. This one is for: DS-638
[20:27] <tdonohue> Heres' the DCAT discussion: https://wiki.duraspace.org/pages/viewpage.action?pageId=23268540
[20:27] <richardrodgers> Well I'd first note that virus checking is in 1.7
[20:27] <kshepherd> yes, virus checking is a curation task
[20:27] <tdonohue> (I believe Elin Stangeland is also in here, if we have questions/comments to add to DCAT's review)
[20:27] <mhwood> Something like that sounds good. We've had a number of bitstreams that were submitted as e.g. PDF which were not actually PDF.
[20:27] <ElinS> Hi all
[20:28] <kshepherd> (though not tested/used by me yet)
[20:28] <tdonohue> richardrodgers, yes, thanks for noting that!
[20:28] <kshepherd> and there is also a Profile Bitstream Formats curation task
[20:28] <richardrodgers> So we should close that ticket, and open a new one with remaining delvierables...
[20:28] <snail> I'd like to point out that anti-virus is an arms-race that we can facilitate but I'd hate to see us directly engaged in
[20:28] <ElinS> I think it would be worth clarifying that if this is already covered by the curation framework then that is fine...
[20:28] <tdonohue> Well, 1/2 of it is covered by Curation tasks (virus scanning). But, the JHOVE part is not yet in DSpace
[20:29] <ElinS> I also wondered why virus and Jhove was combined
[20:29] <robint> Can the curation tasks be invoked as part of the file upload process ?
[20:29] <mhwood> Well, we pushed AV off to an external scanner, right? So it's not *our* arms race.
[20:29] <stuartlewis> robint: Yes - good point - best if it can be checked for viruses before it enters the archive.
[20:29] <richardrodgers> Correct - we hope to have DROID format ID ready for 1.7.1
[20:29] <ElinS> Btw, I think robint's comments from the wiki discussion makes sense
[20:30] <kshepherd> snail: it would be trivial to plug something other than clamav into the virus scanning curation task
[20:30] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[20:30] <richardrodgers> robint: you could, but I'm not convinced that's optimal....
[20:30] <snail> yes, upload first makes a lot of sense, since then we can introspect for metadata too
[20:30] <tdonohue> richardrodgers: why would it be "not optimal" (just curious)
[20:30] <richardrodgers> several reasons:
[20:31] <richardrodgers> first, we take in content that should be checked from 5 or 6 ingest paths (SUbmission, batch, SWORD), et
[20:31] <richardrodgers> etc
[20:32] <richardrodgers> So we either wire virus checking into each path, or put it where all ingest can be checked
[20:32] <robint> I'm coming at this from an angle. My interest is populating metadata from the file contents, but it makes sense to validate the file first.
[20:33] <robint> Would it be reasonable to only invoke the file checking for file types from which metadata could be extracted ?
[20:33] <richardrodgers> So you want to programmatically open the file and extract metadata to put it submission forms?
[20:33] <robint> Yes
[20:34] <richardrodgers> OK - then you can use the curation API, and call virus checking like that
[20:34] <robint> Notably Word docs created with the Author plugin contain a file of DC metadata
[20:34] * tdonohue is worried we're slightly branching off here... DS-638 is just about Virus Scan / Format identification :)
[20:34] <snail> checking is going to be done at every stage in the workflow right? virus signature are going to be updated asynchronously and we need to check before exposing a workflow user to a potentially infected file
[20:35] <ElinS> Would it be possible to create an overview ticket for the curation framework with links to sub-issues? That will make it easier to get an overview of what is going on, and may facilitate further discussion?
[20:35] <richardrodgers> snail: checking can be done wherever you want in workflow
[20:36] <robint> tdonohue: You are right. But if I would happily address the requirements of DS-638 along with my own work.
[20:36] <mhwood> Pre-filling needs to be optional. Otherwise, if you have contributors who always fill documents with *incorrect* metadata, you have to clean that out and then redo it all correctly. Yuck.
[20:37] <tdonohue> robint -- yea, I understand -- it's interesting work, I just don't see why it relates directly to DS-638 (other than that you may want to kick off metadata extraction at the same point during Submission UI). Maybe I'm confused though.
[20:38] <tdonohue> So -- it sounds like we have two things here. (1) Both of these tasks, Virus Scan & File Format Verification are currently implemented or being implemented for Curation Admin UI
[20:39] <ElinS> Is there an issue for file format verification?
[20:39] <tdonohue> (2) The question remains whether it's logical to also kick these tasks off "automatically" during the normal Submission UI process
[20:39] <robint> tdonohue: You understand correctly. Just I would be happy to sweep up DS-638 with my work.
[20:39] <richardrodgers> tdonohue: not just Admin UI, in workflow, command-line, etc
[20:39] <tdonohue> robint: ok -- I understand it now! I'd also be glad for you to "sweep it up" if you are willing :)
[20:40] * kshepherd thinks curation might need some more PR! ;)
[20:40] <grahamtriggs_> mhwood: Metadata extraction should be a non-ui (or maybe with a UI, if you want to be able to select metadata from multiple files uploaded) step, then you just configure the submission steps as upload -> extract -> metadata
[20:40] <mhwood> You open the file already for AV, and for format detection, so it might make sense to do metadata extraction there too. But these are separate issues and can proceed separately. It just wants a stack of plugins to be notified when a file is to be considered.
[20:40] <tdonohue> richardrodgers. Sorry, I misspoke :) Is it actually in the Workflow UI though?
[20:41] <richardrodgers> tdonohue: not sure what you mean by the workflow UI, but it will send notifications to workflow participants - it is a 'background' automated process
[20:42] <richardrodgers> that is part of workflow
[20:42] <kshepherd> take a look at [dspace]/config/workflow-curation.xml to see how it ties in
[20:43] <tdonohue> richardrodgers -- ok. I understand. By Workflow UI I meant is it somehow notifying people of issues ("e.g. Virus Found!") when someone is accessing the Workflow Step from the UI. I didn't realize it was tied in there
[20:43] * helix84 (a@195.113.97.174) has joined #duraspace
[20:44] <richardrodgers> tdonohue: yes, it will report on either all activity, on only when virus found (your choice)
[20:44] <tdonohue> Ok. we should move on now. It sounds like we've gotten somewhere here. It's just a question of whether we want to also integrate these curation tasks into the normal Submission UI process (especially the upload step), to give immediate feedback to submitter
[20:45] <ElinS> In that case I'll move on to the next issue on the DCAT list, great to see this move forward!
[20:45] <robint> I would be happy tp pursue this with the DCAT group. But no action without further consultation.
[20:45] <ElinS> robint: do you want me to help out with that?
[20:46] <robint> ElinS: Cheers, I'll email tomorrow.
[20:46] <tdonohue> robint -- thanks for volunteering to dig in some more
[20:46] <ElinS> Sounds good
[20:47] <tdonohue> Ok, next agenda topic. Revisiting 1.7.1. We now have a few more "annoying" issues (esp. around SWORD submissions) we may want to fix. For a small list see the agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-23
[20:47] <tdonohue> I wanted to bring this up again to see if we now feel it's "time" to schedule a 1.7.1
[20:47] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:47] <kshepherd> ok, so DS-785 is basically fixed by us internally
[20:48] <kshepherd> i just need to sort out the slf4j version mismatch, which means re-releasing dspace-solr maven artifact
[20:48] * kshepherd will make sure to update JIRA today
[20:49] <tdonohue> I'm personally starting to think we need a 1.7.1 to resolve these issues for everyone...
[20:49] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:49] <tdonohue> but, I'd like to hear from everyone else. should we "set a date" to ensure we have a deadline in front of us for 1.7.1?
[20:50] <richardrodgers> Do we have a handle on the other show-stoppers?
[20:51] <tdonohue> DS-821 was caused by me (it's related to refactoring work for the new AIP Backup & Restore). So, I could probably tackle it anytime -- just need to set myself a deadline :)
[20:51] <tdonohue> DS-675 is still "up in the air" -- needs someone to investigate
[20:51] <kshepherd> yeah i dont think anybody has gotten any further on DS-675
[20:52] <tdonohue> Even without a fix for DS-675, I still think a 1.7.1 would be worthwhile in the near future. Combined, both DS-821 and DS-785 make using SWORD a bit "annoying" / problematic in 1.7.0
[20:53] * PeterDietz (sorry was distracted)
[20:53] <kshepherd> yep, agreed
[20:53] <Kevin_VdV> We might also wanna fix DS-823 which was created today
[20:53] <kshepherd> those two are the critical bugs so far
[20:53] <PeterDietz> I would say that I would be interested in scheduling a 1.7.1 soon
[20:53] <tdonohue> Kevin_VdV -- thanks for pointing out DS-823.
[20:53] <kshepherd> hmm, DS-823 seems like a showstopper for Oracle users, +1 to schedule it for 1.7.1
[20:54] <richardrodgers> +1 to start schedule planning
[20:54] <Kevin_VdV> +1
[20:54] <mhwood> +1
[20:54] <tdonohue> Anyone use Oracle, and want to start to investigate DS-823?
[20:54] <tdonohue> +1 to do schedule planning as well.
[20:55] <hpottinger> we use Oracle here in Missouri, and testing 1.7.0 is near the top of my list
[20:56] <tdonohue> So, now that we are on the same page around 1.7.1. Should we set a tentative or "formal" date? Say, in a month? (e.g. March 18? or March 25?) to give us time to get in more of these fixes
[20:57] <kshepherd> sounds good to me
[20:57] <mhwood> Yes
[20:57] <richardrodgers> seems reasonable
[20:58] <PeterDietz> same here, do we make a 1.7.1.rc1?
[20:58] <kshepherd> i don't think we bother with RCs for minor releases
[20:58] <kshepherd> just test thoroughly, release
[20:59] <tdonohue> RC1 is not absolutely required (though if we felt a need we can do one). There usually is not a formal test-a-thon for bug-fix-only releases
[20:59] <PeterDietz> ok, that sounds preferable
[21:00] <mhwood> Why does RC imply a testathon? It's a chance for bug reporters to try out the fixes.
[21:00] <tdonohue> PeterDietz -- you still good with coordinating the 1.7.1 release and cutting it? If so, do you have a preference on a date?
[21:01] <PeterDietz> st patricks day is day before the 18th, that should hopefully imply good luck?
[21:01] <tdonohue> mhwood -- didn't mean to imply that. Those statements were both standalone. I was just noting that we don't always do an RC1, and that we never do a formal test-a-thon for bug fix releases
[21:01] <mhwood> Ah
[21:02] <mhwood> I can't think of a better reason to pick one week over the other.
[21:03] * kshepherd is semi-here from now on
[21:03] <tdonohue> Now that I gave you the choice, I wonder if we should do the 25th :) Just gives us a bit more time to fix up code and ensure we get our Docs updated as needed, as well
[21:03] <PeterDietz> yeah, I can still follow up on all the tagged issues, I'll still try to wiggle as much as possible to not be the one that officially type the release command
[21:04] <tdonohue> PeterDietz -- you should try to get over your fear of a Maven release (it's really not bad, now that it's *fixed*) :) Perhaps a minor release such as this one can be a help (in that it's not a big deal if it goes out slightly late, etc.)
[21:05] <mhwood> I guess it's up to the Release Coordinator to decide when it's ready, though I'm sure constructive input would be appreciated.
[21:06] <robint> Go to go. Cheers all.
[21:06] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:07] <PeterDietz> ok, maybe we'll shoot for the later date (25th), just to have more testing
[21:08] <tdonohue> Ok. Sounds like we have a 1.7.1 tentative date of March 25. So, plan your 1.7.1 bug-fixes appropriately! That means we probably should try to ensure most everything gets into 1.7.x branch by March 18 at the latest
[21:08] <sandsfish> sounds fair
[21:08] <tdonohue> Final thing for today. I'm out-of-the-office next week. Any volunteers to lead the meeting? Possible topics include: More JIRA quick reviews, updates on 1.7.1, other discussions that you see fit
[21:09] <stuartlewis> We'd like to discuss (a topic for next week?) how to structure / distribute custom curation tasks. We've been working on a lot here, some of which are generic and extensible, such as a http link checker for links in the metadata.
[21:10] <PeterDietz> I was just thinking a discussion on curation task would be good. so that sounds like a winner
[21:12] <tdonohue> Sounds like a worthwhile topic to me. Does one of you want to lead a discussion on that next week? (I'll obviously catch up via the IRC logs later on)
[21:12] <mhwood> Yes, an area I need to study anyway.
[21:12] <stuartlewis> Yeah - that sounds fine. Happy to lead.
[21:13] <richardrodgers> I'll be around to take the heat on design issues....
[21:13] <tdonohue> Sounds good. So, next week's discussion concentrates on Curation Tasks, led by stuartlewis
[21:16] <tdonohue> Ok, that's it for today. Meeting is closed, but as always I'll be around for a while if anything comes up...
[21:16] <richardrodgers> thanks all, bye
[21:16] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:16] <sandsfish> cheers all.
[21:16] * sandsfish (~sandsfish@18.111.30.208) Quit (Quit: sandsfish)
[21:17] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[21:21] <Kevin_VdV> Bye all
[21:21] * Kevin_VdV (KevinAtmir@94-227-62-14.access.telenet.be) Quit ()
[21:29] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Read error: Connection reset by peer)
[21:46] * helix84 (a@195.113.97.174) Quit (*.net *.split)
[21:49] * snail (~stuart@130.195.179.88) Quit (*.net *.split)
[21:49] * ianthe (~ianthe@cowu.be) Quit (*.net *.split)
[21:49] * keithgilbertson (~keithgilb@207.138.47.158) Quit (*.net *.split)
[21:49] * grahamtriggs (~grahamtri@62.189.56.2) Quit (*.net *.split)
[21:49] * krnl_ (Andrius@193.219.34.106) Quit (*.net *.split)
[21:49] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) Quit (*.net *.split)
[21:49] * ElinS (56097ad4@gateway/web/freenode/ip.86.9.122.212) Quit (*.net *.split)
[21:49] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (*.net *.split)
[21:49] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) Quit (*.net *.split)
[21:49] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (*.net *.split)
[21:49] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (*.net *.split)
[21:49] * Mayank (~beakkon@122.162.139.179) Quit (*.net *.split)
[21:49] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (*.net *.split)
[21:49] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) Quit (*.net *.split)
[21:49] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (*.net *.split)
[21:49] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (*.net *.split)
[21:49] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[21:49] * DuraLogBot (~PircBot@atlas.duraspace.org) Quit (Ping timeout: 240 seconds)
[21:49] * Disconnected.
[21:49] -zelazny.freenode.net- *** Looking up your hostname...
[21:49] -zelazny.freenode.net- *** Checking Ident
[21:49] -zelazny.freenode.net- *** Found your hostname
[21:49] -zelazny.freenode.net- *** No Ident response
[22:39] * Disconnected.
[22:39] -hubbard.freenode.net- *** Looking up your hostname...
[22:39] -hubbard.freenode.net- *** Checking Ident
[22:39] -hubbard.freenode.net- *** Found your hostname
[22:39] -hubbard.freenode.net- *** No Ident response
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.