Timestamps are in GMT/BST.
[0:13] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[1:50] <dungth> hi all
[1:50] <dungth> is there anyone there ?
[1:55] <snail> dungth: don't ask to ask, just ask
[2:00] <dungth> 'm confused about the resource policy !!
[2:00] <dungth> i disabled anonymous access on Collection level (item read)
[2:00] <dungth> but if an item in that collection allow anonymous access
[2:00] <dungth> then anonymous user can access that item
[2:01] <dungth> i have many items in that situation !
[2:01] <dungth> but how to disablethe anonymous access to those items ?
[2:01] <dungth> of course not by the way item-by-item !
[2:12] <snail> dungth: items inherit the policy at the time they were created, I believe
[2:12] <dungth> oh
[2:12] <dungth> that's right
[2:13] <dungth> but then if we change the collection policy
[2:13] <dungth> how to change the item policies
[2:13] <dungth> i mean the system policies are not synchronous
[2:14] <dungth> so my problem is that: a user can directly access items if he know the item's url, but he can't access items via collection
[2:15] <dungth> but he still can access via the way browse-by-date/author
[2:27] <dungth> i have a solution for this: it's editing the table resourcepolicy
[2:28] <dungth> so that it replace all 0 group( anonymous ) to a specified group
[2:28] <snail> dungth: i guess so, I've never done anything like that
[2:28] <dungth> one more: do u know resource type id ?
[2:28] <dungth> 0 is for bitstream, 1 for item ??
[2:30] <snail> dungth: no idea, sorry
[3:40] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[3:51] * ksclarke (~kevin@adsl-235-99-153.clt.bellsouth.net) Quit (Quit: Leaving.)
[3:57] * alxp (~aoneill@171.66.90.251) Quit (Quit: alxp)
[3:59] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[4:34] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[4:34] * eddies (~eddies@unaffiliated/eddies) Quit (Client Quit)
[4:36] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[4:37] * eddies (~eddies@unaffiliated/eddies) Quit (Client Quit)
[5:55] * cwilper (ad579d07@gateway/web/freenode/ip.173.87.157.7) Quit (Ping timeout: 252 seconds)
[6:49] -hitchcock.freenode.net- *** Looking up your hostname...
[6:49] -hitchcock.freenode.net- *** Checking Ident
[6:49] -hitchcock.freenode.net- *** Found your hostname
[6:49] -hitchcock.freenode.net- *** No Ident response
[6:49] [frigg VERSION]
[6:49] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:49] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:49] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:40] * cwilper (ad579d07@gateway/web/freenode/ip.173.87.157.7) has joined #duraspace
[12:10] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:31] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[13:53] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
[15:25] * pandorra (~pandorra@195.22.112.82) has joined #duraspace
[16:01] * pandorra (~pandorra@195.22.112.82) has left #duraspace
[16:50] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[17:28] * alxp (~aoneill@171.66.92.240) has joined #duraspace
[18:10] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[18:11] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[18:50] * ChrisGT (~Adium@merovingian.library.gatech.edu) has joined #duraspace
[19:03] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[19:06] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:34] * ChrisGT (~Adium@merovingian.library.gatech.edu) has left #duraspace
[19:39] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:41] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) Quit (Remote host closed the connection)
[19:41] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:46] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) has joined #duraspace
[19:49] <tdonohue> Hi all, the DSpace Developers Mtg starts here in a little over 10 mins. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-23
[19:49] <kompewter> [ DevMtg 2011-03-23 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-23
[19:53] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) has joined #duraspace
[19:54] * cccharles (~chris@131.104.62.48) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome. Here's today's agenda for our DSpace Developers mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-23
[20:00] <kompewter> [ DevMtg 2011-03-23 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-23
[20:00] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <tdonohue> We'll start off today's meeting with a JIRA Quick Review (2 mins per issue). Any volunteers to either post issues or summarize?
[20:01] <tdonohue> Here's the list of issues that we still need to review, if you want to follow along: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-740+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-740 ] - [#DS-740] Allow media filter to set non-default permissions on derivative bitstreams - DuraSpace JIRA
[20:01] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-740+ORDER+BY+key+ASC
[20:02] <tdonohue> (looks like that link confused kompewter)
[20:02] * cwilper (ad579d07@gateway/web/freenode/ip.173.87.157.7) Quit (Ping timeout: 252 seconds)
[20:02] <kshepherd> heh
[20:02] <PeterDietz> hey, it extracted the first hit
[20:02] <kshepherd> nice
[20:02] <tdonohue> PeterDietz -- kinda -- it actually pulled "DS-740" out of the link :)
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-740 ] - [#DS-740] Allow media filter to set non-default permissions on derivative bitstreams - DuraSpace JIRA
[20:03] <tdonohue> in any case, we're starting with DS-740...so, let's begin it's review now
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-740 ] - [#DS-740] Allow media filter to set non-default permissions on derivative bitstreams - DuraSpace JIRA
[20:03] <kshepherd> idea is good, no patch..
[20:04] <mhwood> Shouldn't that rather be an attribute of the collection?
[20:04] <richardrodgers> i agree, needs a sponsor since it's really a feature request
[20:04] <mhwood> Anyway it does expose a problem.
[20:05] <stuartlewis> A slightly related thing was chatted about on here yesterday - the ability to change en-masse authorizations (e.g. 'I've updated the default perms of this collection, now re-apply it to all items in this collection')
[20:05] <tdonohue> +1 to further analysis here...needs a volunteer
[20:05] <tdonohue> stuartlewis -- that sounds like a different feature request :)
[20:06] <tdonohue> (but also a good idea, I think)
[20:06] <PeterDietz> is the problem that ORIGINAL is restricted, thus so is THUMBNAIL, and on browse pages, they try to use the THUMBNAIL and it makes you login to browse
[20:06] <kshepherd> no, the opposite i think
[20:06] <kshepherd> the ORIGINAL is restricted, because nobody is supposed to see it
[20:06] <kshepherd> but the THUMBNAIL is generated with open access
[20:06] <stuartlewis> Yes, different, but could be used to tackle the same problem if it were possible to assign default perms for thumnails.
[20:06] <kshepherd> and copyright is broken, or whatver
[20:07] <mhwood> So a container needs 1 default ACL for original bitstreams and another for derived bitstreams. Maybe they should be tagged with bundle names....
[20:07] <kshepherd> it does raise the question of what should happen when an anonymous or unauthorised person tries to look at, say, a browse page
[20:07] <mdiggory> thats a strong assumption that thumbnails should be open access
[20:08] <tdonohue> sounds like we are unsure about DS-740... needs volunteer, further analysis, and suggestions on best way to fix
[20:08] <kshepherd> a redirect to a login page would be confusing if someone thinks they're just browsing a collection to see titles/authors or something
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-740 ] - [#DS-740] Allow media filter to set non-default permissions on derivative bitstreams - DuraSpace JIRA
[20:08] <mdiggory> your really going violate someones privacy for the sake of a thumbnail?
[20:08] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:08] <tdonohue> any volunteers for 740?
[20:10] <kshepherd> *tumbleweed*
[20:10] <tdonohue> OK -- moving on, spent too much time already. Please add comments to 740 if you have any thoughts on best route forward.
[20:10] <tdonohue> Next up: DS-742
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-742 ] - [#DS-742] Embargo Fails with Null Pointer Exception on Item Install. - DuraSpace JIRA
[20:10] <mdiggory> If the bitstream is restricted, so should the thumbnail, and the UI should detect that and not show it in search/browse (use a placeholder instead)
[20:10] <kshepherd> mdiggory: yep that sounds best
[20:10] * Joseph_Rhoads (a00a0f16@gateway/web/freenode/ip.160.10.15.22) has joined #duraspace
[20:10] <mhwood> Already assigned.
[20:11] <kshepherd> 742 looks like it's probably resolved already?
[20:11] <tdonohue> mdiggory, is 742 resolved?
[20:11] <mdiggory> oh... that one...
[20:12] <mdiggory> resolved
[20:12] <tdonohue> Summary: DS-742 - leave assigned to mdiggory & mark resolved
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-742 ] - [#DS-742] Embargo Fails with Null Pointer Exception on Item Install. - DuraSpace JIRA
[20:12] <tdonohue> Next one: DS-749
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-749 ] - [#DS-749] allow for bitstream display order to be changed - DuraSpace JIRA
[20:12] <kshepherd> an oldie but a goodie ;)
[20:13] <mdiggory> kompewter rules
[20:13] <mdiggory> aahh PERL code
[20:13] <PeterDietz> Ds-749 is a feature improvement, involves a new field in DB
[20:14] <tdonohue> yea, it also has perl code :(
[20:14] <kshepherd> and people ask for it all the time
[20:15] <tdonohue> +1 to the idea. Needs analysis and improvements on implementation (no perl code please)
[20:15] <kshepherd> heh
[20:15] <richardrodgers> my vote would be to add it to the 'general metadata on DSpace objects' project....
[20:15] <kshepherd> also +1 to the general idea, think the impl could be a bit more simple
[20:15] <mhwood> +1 idea
[20:15] * dungth (~chatzilla@123.27.252.29) Quit (Read error: Connection reset by peer)
[20:16] <tdonohue> Any volunteers to look at? Should we add to 'metadata on all objects' project (like richardrodgers suggests)?
[20:16] <mdiggory> TBH, I don't like how this is written
[20:16] <mdiggory> -1
[20:17] <kshepherd> how would it work as metadata?
[20:17] <mdiggory> Order is an attribute of the Bundle the Bitstream are in, not the Bitstream itself
[20:17] <kshepherd> i would have thought it was more of a bitstream table thing
[20:17] <KevinVdV> What about using sequence id ?
[20:18] <KevinVdV> To hold the order
[20:18] <kshepherd> mdiggory: well... that's not going to appease all the repository managers who want to line up the multiple PDFs they have in ORIGINAL, etc..
[20:18] <tdonohue> Summary DS-749: +1 total, several concerns about implementation, but idea is good. Needs volunteer to analyze & suggest a resolution
[20:18] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-749 ] - [#DS-749] allow for bitstream display order to be changed - DuraSpace JIRA
[20:18] <PeterDietz> sequence_id = internal, can't be used for display, might break things
[20:18] * tdonohue reminds us that we are trying to do 'quick reviews' here :)
[20:18] <mdiggory> kshepherd: not saying its not important... saying its implemented in the JIRA ticket wrong
[20:18] <PeterDietz> DS-192 allows for sorting based on order
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-192 ] - [#DS-192] Bitstreams should be returned ordered - DuraSpace JIRA
[20:18] <kshepherd> oh yeah well i was +1 idea, not +1 patch, to be clear ;)
[20:19] <PeterDietz> ...and this one needs to be implemented as slick drag-n-drop for reordering
[20:19] <tdonohue> In essence of time, moving on to next one: DS-750
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-750 ] - [#DS-750] Cleanup display of Curation Admin UI to make more human readable/understandable - DuraSpace JIRA
[20:19] <mdiggory> sorry, my vote was for applying the patch (if thats what posting code into a description is)
[20:19] <tdonohue> (Please feel free to add impl details/ideas directly to Ds-749 if you have them)
[20:19] <mdiggory> +1 for idea, needs to be written properly though
[20:20] <richardrodgers> Think DS-750 is resolved
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-750 ] - [#DS-750] Cleanup display of Curation Admin UI to make more human readable/understandable - DuraSpace JIRA
[20:20] <tdonohue> richardrodgers -- yea, I think main concerns were resolved in 750. Feel free to resolve it
[20:20] <richardrodgers> k, will do
[20:20] <mdiggory> KevinVdV: sequence id is an idea, concern is that we are currently overloading sequence id with subtile versioning safeguards
[20:20] <tdonohue> Last one for today: DS-754
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-754 ] - [#DS-754] Revisit Browse-By Responses for DSpace 1.8.0 - DuraSpace JIRA
[20:21] <kshepherd> sequence id is also used in bitstream urls (so change it, and google links might break?)
[20:21] <mdiggory> if we abandon using sequenceid as a subtile mechanism for showing the difference between two bitstreams with the same name... then it could be used for ordering
[20:22] <kshepherd> can'd do anything on DS-754 until DS-640 is done, really
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-754 ] - [#DS-754] Revisit Browse-By Responses for DSpace 1.8.0 - DuraSpace JIRA
[20:22] <tdonohue> that's right, I put in 754 as a placeholder to revisit DS-640. But, since we never actually resolved DS-640 (still assigned to kshepherd), I'm guessing that 754 is not really valid anymore
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-640 ] - [#DS-640] Interal System Error when browsing with wrong argument - DuraSpace JIRA
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-640 ] - [#DS-640] Interal System Error when browsing with wrong argument - DuraSpace JIRA
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-640 ] - [#DS-640] Interal System Error when browsing with wrong argument - DuraSpace JIRA
[20:22] <kshepherd> i was up very late last night battling with it
[20:23] <kshepherd> it's a huge pain
[20:23] * tdonohue ack! kompewter is a little crazy at times
[20:23] <PeterDietz> .rmpoint kompewter
[20:23] <kompewter> kompewter: +1/-1, 0
[20:23] <mdiggory> but likewise, if you use it, google would update the bitstreams its caching accordingly and deleted bitstreams wouldn't remain cached when replacing a bitstream in a DSpace item
[20:23] <kshepherd> and we're still not going to get 404, so i'm not sure it's even worth the effort to cram it into 1.7.1
[20:23] <kshepherd> but i'll try
[20:24] <tdonohue> kshepherd -- in my mind it's more important for 1.8.0. I wouldn't worry too much if it misses 1.7.1 (though obviously it'd be nice)
[20:24] <richardrodgers> it is a unique, persistent handle sub-identifier for bitstreams
[20:24] <kshepherd> richardrodgers: i remember we talked a bit about it at the devs meeting at OR09
[20:24] <kshepherd> can't remember how it came up..
[20:24] <tdonohue> Ok. Stopping JIRA review there for today
[20:25] <tdonohue> Next up on agenda: Updates on 1.7.1
[20:26] <tdonohue> Obviously, we're scheduled for release on Friday. How are we looking, PeterDietz?
[20:26] <PeterDietz> One bug I would have liked to have seen fixed was DS-768
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:26] <PeterDietz> ..plus I need some feedback about sword+discovery slf4j problem
[20:27] <richardrodgers> PeterDietz: +1, me too
[20:27] <mdiggory> richardrodgers: not sure I really need a unique persistent sub-identifier for bitstream ;-) but if someone else does... so-be-it
[20:27] <kshepherd> ok
[20:27] <kshepherd> PeterDietz: that's a cocoon bug, i don't know how we can fix it
[20:27] <kshepherd> but it's a pretty big problem alright :/
[20:27] <tdonohue> PeterDietz -- DS-768 is "impossible" right now, as it's a Cocoon bug (see the notes).
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:27] <kshepherd> kompewter: shush
[20:28] <tdonohue> kompewter just gets too excited sometimes :)
[20:28] <richardrodgers> mdiggory: fair enough, just pointing out that that was what it was designed for
[20:28] <mdiggory> hmmm, I thought we had addressed this already... yes they should return a 404
[20:28] <kshepherd> PeterDietz: re DS-785
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-785 ] - [#DS-785] SWORD deposits fail when ingest events are fired if Discovery event consumer is configured - DuraSpace JIRA
[20:29] <mhwood> We did, but it broke again.
[20:29] <kshepherd> PeterDietz: it's fixed.. was a much simpler fix than i first proposed
[20:29] <tdonohue> Again, DS-768 is a *Cocoon* bug. We didn't break anything...See: https://issues.apache.org/jira/browse/COCOON-2218
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:29] <kompewter> [ [#COCOON-2218] Unable to set response code of 404 in map:handle-errors - ASF JIRA ] - https://issues.apache.org/jira/browse/COCOON-2218
[20:29] <kshepherd> i've committed to trunk and 1.7.1 and resolved the issue
[20:29] <richardrodgers> is there any help on the horizon from Cocoon?
[20:30] <PeterDietz> ahh sweet, I was waiting for the GitHub bot attack in #dspace
[20:30] <tdonohue> Cocoon has fixed it, but hasn't formally released it. It will be in Cocoon 2.2
[20:30] <mhwood> /\/\/\/\/\
[20:30] <mdiggory> To be honest, there are larger issues with some of the cahcing work that Larry Stone did that relate to the 404's as well
[20:30] <kshepherd> i thought we *did* use 2.2?
[20:30] <mhwood> There's actually going to *be* a <cocoon-3 release?
[20:30] <PeterDietz> then the dspace-commit issue fix is good, we'll just have to commit that immediately before release+announce
[20:31] <richardrodgers> can we back-port the relevant code?
[20:31] <mdiggory> I would verify if its our use of cocoon that is wrong here, not cocoon itself
[20:32] <tdonohue> any volunteers to look closer at DS-768 then? From what I could tell, it is a Cocoon bug, but it's worth someone else looking at it
[20:32] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:32] <kshepherd> PeterDietz: mdiggory comitted the fix for that, needs new release of dspace-solr
[20:32] <tdonohue> Oh, and as to the Cocoon 2.2 question -- we are using 2.2 in DSpace. Unfortunately, this bug was marked resolved *after* the 2.2 release, and Cocoon has never released a 2.2.1
[20:33] <kshepherd> exactly
[20:33] <kshepherd> they don't seem to want to support their latest stable version :P
[20:33] <PeterDietz> ok, so with all that said, we're looking good for 1.7.1 release
[20:33] <kshepherd> it's "fixed in trunk", with no sign of a patch or commit history, etc
[20:33] <mdiggory> yes, we have generally backported changes for 2.2 into our own module release
[20:34] <mhwood> Uhhuh. 3 years later.
[20:34] <kshepherd> yep :(
[20:34] <kshepherd> while 3.0 is still "alpha"
[20:34] <kshepherd> i really don't get it
[20:34] <tdonohue> if someone wants to look into backporting this Cocoon fix, I'd be all for it :) volunteers?
[20:34] <mdiggory> I'm avoiding discussing cocoon's release process... sorry better to focus on a fix of our own
[20:35] <kshepherd> mdiggory: very pragmatic ;) we gotta fix it somehow!
[20:35] <mdiggory> possible trick... write a servlet filter around cocoon servlet that will detect and set 404 in response
[20:35] <mhwood> How do you detect that 200 really should be 404?
[20:36] <mdiggory> by looking at teh content being dumped into the response, caching and setting the ehader when you detect it was the 404 page
[20:36] <mdiggory> then dumping the content into the response
[20:36] <mdiggory> its a hack... seriously a hack
[20:37] <richardrodgers> a bit fragile, but maybe better than nothing...
[20:37] <mdiggory> possibly in the "bad" hack ;-)
[20:37] <tdonohue> or alternatively, you *can* switch all responses to 500 (or something else), and catch that and change to a 404. (still a hack)
[20:37] <tdonohue> See my comment at the end of DS-768: 500 responses work *fine*, it's only 404s that don't work
[20:37] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:37] * cwilper (ad579d07@gateway/web/freenode/ip.173.87.157.7) has joined #duraspace
[20:38] <mhwood> x-real-status: 404
[20:38] <mdiggory> tdonohue: mhwood thats an idea...
[20:38] <kshepherd> tdonohue: if i can figure out backporting cocoon changes and test the latest snapshot of 2.2 trunk (http://svn.apache.org/snapshots/cocoon/) i could take the issue
[20:39] <tdonohue> feel free, kshepherd. I'd like someone else to take it -- I did a lot of research initially, and it all seemed to point back to that cocoon issue. So, I feel like I had my fair share of time on 768 :)
[20:40] <kshepherd> oh, i have a 1.7.1 question
[20:40] <mdiggory> I already did do a backport and release that was a bit dicey for cocoon... kshepherd I would be glad to consult for you if you want to take it on
[20:40] <richardrodgers> so do we want to hold 1.7.1 pending this analysis?
[20:40] <tdonohue> Ok..back to 1.7.1. Any other updates? PeterDietz, do you need/want any help on final release stuff in preparation for Friday (e.g. Docs, packaging the release, etc)?
[20:40] <kshepherd> i've noticed there is inconsistent use of CHANGES -- nobody's using it for 1.8.0, which is good, but about 60% of 1.7.1 changes are in there, the other 40% arent
[20:41] <tdonohue> I'd be -1 on holding 1.7.1. We've got other issues that need fixing. But, we could always do a small 1.7.2 later on, just to fix DS-768
[20:41] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:41] <kshepherd> is this supposed to be the last release we use CHANGES, or should we rip teh 1.7.1 stuff out and just keep the confluence link?
[20:41] <PeterDietz> I need eyes to review the upgrade/install doc
[20:42] <PeterDietz> ...and then this is the release I'm planning to bite the bullet and actually perform the release, so I've got the release portion
[20:42] <tdonohue> volunteers to look at upgrade/install docs?
[20:42] <PeterDietz> if anyone is changed the other modules, i.e. re-releasing solr/etc
[20:43] <mhwood> I can look at docs.
[20:43] <mdiggory> kshepherd: I would prefer to see confluence / jira be the changes file source... tempted to say to rip it out because I really do not want to use it anymore.
[20:43] <tdonohue> Re: CHANGES. We also have this tracked automatically now in our Wiki Docs at: https://wiki.duraspace.org/display/DSDOC/History
[20:43] <kompewter> [ History - DSpace Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC/History
[20:44] <mdiggory> still need to release dspace-solr and update version numbers
[20:44] <kshepherd> yeah i know.. just wondering whtether some were confused about when we move to it
[20:44] <kshepherd> because at the moment, it looks bad.. not all the 1.7.1 changes are in there
[20:44] <kshepherd> i'm +1 for removing the 1.7.1 sectino as well
[20:44] <kshepherd> and just having the confluence history link
[20:45] <robint> I've been forgetful about updating CHANGES. +1 for dumping it now if possible.
[20:45] <mdiggory> History page is quite nice. and this goes intot he PDF for docs for the relase right?
[20:45] <tdonohue> +1 for dumping CHANGES altogether, and just changing it to point at Confluence History link
[20:45] <richardrodgers> +1 dump CHANGES - we have better mechanisms now
[20:45] <mdiggory> also recommend droppiing the html version of the docs that are in the release, just providing the pdf should be sufficient
[20:45] <tdonohue> yes, the History page goes into the PDF for the release
[20:45] <kshepherd> cool, let's do it
[20:46] <PeterDietz> ...hopefully jtrimble has some free time and can pump out a PDF in short notice, (/me bites finger nails)
[20:46] <tdonohue> PeterDietz -- instructions for generating PDF & HTML docs are in the Release Procedure :)
[20:47] <tdonohue> See: https://wiki.duraspace.org/display/DSPACE/Release+Procedure#ReleaseProcedure-EnsureHTML%26PDFversionsofWikiDocumentationisinSVN
[20:47] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure#ReleaseProcedure-EnsureHTML%26PDFversionsofWikiDocumentationisinSVN
[20:47] <mdiggory> note, documentation still accounts for the major portion of the release distribution.
[20:47] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Quit: keithgilbertson)
[20:47] <mdiggory> everything else is just a few config files and maven poms
[20:48] <tdonohue> Any last notes on 1.7.1? PeterDietz, if you need more help, feel free to ask!
[20:49] <tdonohue> Ok. Next topic: GSoC 2011. Please add more ideas or volunteer to mentor here: https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:49] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:49] <tdonohue> Also, I added some more notes on GSoC to our agenda. We've got some new 'duraspace-gsoc' listservs this year, which we will share with Fedora GSoC & DuraCloud GSoC
[20:50] <mdiggory> excellent
[20:50] <tdonohue> But, the most important thing is to gather more GSoC Project Ideas together -- students start applying on MONDAY! :)
[20:51] <richardrodgers> tdonohue: they can show up with their own ideas/proposals also, yes?
[20:51] <mdiggory> Quite true... yes they can...
[20:51] <tdonohue> yes, students can come with their own ideas..but they don't often do, unless they are already familiar with DSpace
[20:52] <tdonohue> And, we can continue to add ideas during the entire Student Application period (March 28-April 8). But, obviously the later they are added, the less likely we may find a student
[20:52] <richardrodgers> I wasn't discouraging our putting up more - just didn't want to exclude good ideas from elsewhere
[20:53] <tdonohue> Any other questions /comments on GSoC? (Again, we still need mentors too! If you are interested, add your name to our Ideas page)
[20:54] <tdonohue> Ok, last official topic for today is just a note about the OR11 DSpace Developers Mtg. Please sign up if you are planning to attend: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting
[20:54] <kompewter> [ DevMtg 2011-06-06 - OR11 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting
[20:54] <tdonohue> I'll be sending an official invite to dspace-devel later this week as well, to invite other interested developers
[20:54] <richardrodgers> tdonohue: any chance of getting a hotel block for that day if there are enough of us?
[20:54] <tdonohue> Also, if you have agenda ideas, feel free to forward on, or add to the above wiki page.
[20:55] <kshepherd> tdonohue: i haven't been approved to go to OR11 yet, though i'm hoping to. should i put my name down just in case?
[20:55] <tdonohue> richardrodgers -- I can ask around, but I've heard that there's a conference just before us on Monday, so a block likely would *not* be in the official conference hotel
[20:56] <richardrodgers> damn - just trying to keep it cheap
[20:56] <tdonohue> kshepherd -- yea, go ahead and add your name. Feel free to add a section below for "Hope to attend" :) I'm just trying to get some sort of general count
[20:57] <mhwood> Day's Inn University (just NE of campus) had good reviews. I don't know it myself (yet).
[20:57] <tdonohue> richardrodgers: I understand. I also wish we would've either had a hotel block provided, or they could've fit our meeting in on Tues. But, neither seemed possible
[20:59] <tdonohue> Any other thoughts/questions/comments for today? I don't have anything else official to report on my end. Just looking forward to 1.7.1 release
[21:00] <PeterDietz> I'm on the want to, awaiting approval ( from wife, since baby is expected two weeks later)
[21:00] <tdonohue> (btw, PeterDietz -- I'm definitely willing help you with 1.7.1 Release Announcements, obviously. )
[21:01] <stuartlewis> mhwood: Thanks for the suggestion - looks good: http://www.tripadvisor.com/Hotel_Review-g30196-d98416-Reviews-Days_Inn_Austin_University_Downtown-Austin_Texas.html and $74 per night
[21:01] <kompewter> [ Days Inn Austin University / Downtown (Austin, TX) - Motel Reviews - TripAdvisor ] - http://www.tripadvisor.com/Hotel_Review-g30196-d98416-Reviews-Days_Inn_Austin_University_Downtown-Austin_Texas.html
[21:01] * Joseph_Rhoads (a00a0f16@gateway/web/freenode/ip.160.10.15.22) Quit (Quit: Page closed)
[21:02] <tdonohue> There. I added a "May Be Attending" list to the OR11 Meeting Signup. Feel free to add your names there as need be: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting#DevMtg2011-06-06-OR11Meeting-SignUptoAttend\!
[21:02] <kompewter> [ DevMtg 2011-06-06 - OR11 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting#DevMtg2011-06-06-OR11Meeting-SignUptoAttend\!
[21:03] <tdonohue> Ok. Looks like that's it for today. Meeting Adjourned! I'll stick around though in case there are any comments/questions.
[21:04] <PeterDietz> mdiggory: can you release solr and update the project numbers today/tomorrow?
[21:04] <richardrodgers> Thanks everyone, bye
[21:04] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:05] <mhwood> Me too: 'bye all.
[21:05] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:07] * cwilper (ad579d07@gateway/web/freenode/ip.173.87.157.7) has left #duraspace
[21:07] <tdonohue> PeterDietz -- FYI, looks like the language packs will also need a new release for 1.7.1. That could be done today/tomorrow even. Instructions at: https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[21:07] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[21:08] <kshepherd> cheers all
[21:09] <mdiggory> PeterDietz Yes, we will be doing dspace-services as well.
[21:10] <tdonohue> mdiggory -- just make sure to time it appropriately so that any necessary pom updates make it into 1.7.1 release
[21:11] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) Quit (Quit: Page closed)
[21:13] <mdiggory> what time is the release planned for friday?
[21:14] <mdiggory> PeterDietz: I think that was directed at you....
[21:15] <PeterDietz> hi mdiggory, I don't have a calendar of events, so I was reading of the release procedure, to find out the time-break-down I might need
[21:15] <PeterDietz> I would think after lunch I'll start the process
[21:16] <mdiggory> EST?
[21:16] <PeterDietz> yep, do you have some preferences
[21:16] <PeterDietz> actually EDT, due to time shift
[21:16] <mdiggory> yea whatever time zone snob
[21:16] <mdiggory> ;-)
[21:17] <mdiggory> got to have that extra time in the morning to sow the fields before school
[21:18] <PeterDietz> the daylight is helpful for me to stay later at work, since its still bright out, I might as well stay at work for an extra hour
[21:18] <mdiggory> we'll try to get the services and dspace-solr out tonite/tomorrow.
[21:18] <mdiggory> that excuse does not go over well with the wife...
[21:19] <PeterDietz> ok, then for secret dspace-commit patch, I'll commit that before kicking off release,
[21:19] <mdiggory> sshhh'
[21:21] <mdiggory> seems like they failed to attach the jira id to the commit on this one.
[21:21] <mdiggory> https://issues.apache.org/jira/browse/COCOON-2218?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel#issue-tabs
[21:21] <kompewter> [ [#COCOON-2218] Unable to set response code of 404 in map:handle-errors - ASF JIRA ] - https://issues.apache.org/jira/browse/COCOON-2218?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel#issue-tabs
[21:26] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[21:36] * keithgilbertson (~keithgilb@207.138.47.158) has left #duraspace
[21:47] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) Quit (Quit: KevinVdV)
[22:02] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[22:33] <kshepherd> mdiggory: i know :( annoying
[22:33] <kshepherd> i've grabbed the snapshot
[22:34] <kshepherd> will see if i can trace back revision history to the dates/ids
[22:35] <mdiggory> for cocoon?
[22:35] <kshepherd> mm
[22:36] <kshepherd> oh, hrm, i see the actual repos
[22:36] <kshepherd> that'll be easier :P
[22:37] <mdiggory> I like the request header idea.... catch it later in the filter and adjust the status if its incorrect. thats a good safety measure...
[22:37] <mdiggory> request = response
[23:06] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.