Timestamps are in GMT/BST.
[0:06] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Ping timeout: 246 seconds)
[1:46] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[1:57] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (Quit: alxp)
[2:52] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[3:10] <snail> stuartlewis / kshepherd: got to the bottom of my SWORD issues. didn't work through httpd virtual hosting but worked from localhost directly to port 8080, so almost certainly my httpd config is broken. Seems like SWORD is the only part of dspace that actually requires the host name components of URLs to be right?
[3:10] <stuartlewis> Yep.
[3:11] <stuartlewis> Not sure if the restriction is too harsh.
[3:12] <snail> stuartlewis: no the restriction is not too harsh (because an exploit could cause havoc), but the error / warning messages are not explicit enough
[3:14] * snail gone
[3:54] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[5:49] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[6:00] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[6:28] -card.freenode.net- *** Looking up your hostname...
[6:28] -card.freenode.net- *** Checking Ident
[6:28] -card.freenode.net- *** Found your hostname
[6:28] -card.freenode.net- *** No Ident response
[6:28] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:28] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:28] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:57] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[7:02] * Mayank1 (~MnzNotebu@122.173.195.53) has joined #duraspace
[7:13] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[7:14] * Mayank1 is now known as Mayank
[7:52] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[8:08] * Mayank (~MnzNotebu@122.173.195.53) Quit (Quit: Leaving.)
[8:14] * Mayank (~MnzNotebu@122.173.195.53) has joined #duraspace
[8:42] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[9:26] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[9:36] * Mayank (~MnzNotebu@122.173.195.53) Quit (Quit: Leaving.)
[10:55] * ianthe (~ianthe@cowu.be) has joined #duraspace
[10:56] * ianthe (~ianthe@cowu.be) has left #duraspace
[11:56] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (Quit: alxp)
[12:28] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[12:57] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[13:24] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:57] * ksclarke (~kevin@adsl-39-65-246.clt.bellsouth.net) Quit (Read error: Connection reset by peer)
[13:57] * ksclarke1 (~kevin@adsl-39-65-246.clt.bellsouth.net) has joined #duraspace
[14:34] * ksclarke1 (~kevin@adsl-39-65-246.clt.bellsouth.net) Quit (Ping timeout: 264 seconds)
[14:34] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:34] * ksclarke (~kevin@adsl-39-65-246.clt.bellsouth.net) has joined #duraspace
[14:38] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:58] * neanlos (~neanlos@190.144.163.85) has joined #duraspace
[14:58] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[14:58] <neanlos> Good morning to everyone!
[15:13] <neanlos> Does anyone know a good method to find errors during the update process of dspace.cfg?
[15:13] -card.freenode.net- *** Looking up your hostname...
[15:13] -card.freenode.net- *** Checking Ident
[15:13] -card.freenode.net- *** Found your hostname
[15:13] -card.freenode.net- *** No Ident response
[15:13] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[15:13] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[15:13] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[15:45] * neanlos1 (~neanlos@190.144.163.85) has joined #duraspace
[15:47] * neanlos (~neanlos@190.144.163.85) Quit (Ping timeout: 240 seconds)
[17:34] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[18:13] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[18:25] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[18:29] * stuartlewis (~stuartlew@121.98.157.79) Quit (Client Quit)
[19:24] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:30] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:35] * neanlos (~neanlos@190.144.163.85) has joined #duraspace
[19:39] * neanlos1 (~neanlos@190.144.163.85) Quit (Ping timeout: 265 seconds)
[19:47] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) has joined #duraspace
[19:52] <tdonohue> Reminder: at the top of the hour, there's a DSpace Developers Meeting here. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-26
[19:56] * cccharles (~chris@131.104.62.55) has joined #duraspace
[19:58] * jefftrimble (~jefftrimb@pool-70-20-65-250.pitbpa.east.verizon.net) has joined #duraspace
[19:58] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[19:59] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) has joined #duraspace
[20:00] * PeterDietz (~PeterDiet@128.146.175.194) has joined #duraspace
[20:00] <tdonohue> Hi all -- time to begin the weekly DSpace Developers Mtg. As usual, we'll start with some JIRA reviews...beginning with DS-669 today
[20:00] <tdonohue> here's a link of issues to be reviewed: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-669+ORDER+BY+key+ASC
[20:01] <tdonohue> icons of restricted bitstreams : https://jira.duraspace.org/browse/DS-669
[20:01] * tdonohue today's agenda if you haven't seen it is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-26
[20:01] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:02] <stuartlewis> Did it used to work that way?
[20:02] <PeterDietz> does this patch skip the auth check on the icons if there are no publicly viewable ORIGINAL bitstreams?
[20:02] <stuartlewis> What if you aren't logged in, but could read it if you were?
[20:03] <sandsfish> sounds like something that would be nice to configure (either display protected or not at all)
[20:03] <stuartlewis> What does he mean by icon? Thumbnail?
[20:03] * Mayank (~beakkon@122.173.195.53) has joined #duraspace
[20:03] <PeterDietz> i think thumbnail is what is meant
[20:03] <tdonohue> I think he means the actual bitstream link
[20:04] <tdonohue> See DS-611 for more background: https://jira.duraspace.org/browse/DS-611 (includes comments by Claudia)
[20:04] <sandsfish> looks like the patch just doesn't render any detail if there's no bundle access.
[20:04] <PeterDietz> when you restrict access to an ORIGINAL bitstream, it would be helpful if derivative bitstreams are also permission changed as well (atleast the option to keep them in sync)
[20:04] <tdonohue> So, it looks like DS-669 is the same as DS-611 (it was just added again)
[20:05] <grahamtriggs> PeterDietz: option to keep them in sync. It's entirely reasonable to want to display the thumbnail, but restrict access to the full image
[20:06] <PeterDietz> bah, i want a one-size-fits-none repository
[20:06] <tdonohue> Anyone willing to investigate DS-669 further -- sounds like someone should do some digging into seeing what actually did change between 1.5 and 1.6, and look into our various options
[20:07] <sandsfish> i'll dig into it. you can assign it to me.
[20:08] <tdonohue> Ok, assign DS-669 to sandsfish. He'll investigate and get back to us with more details/possible solutions
[20:08] <tdonohue> Nullpointer exception when bogus information is entered in the Embargo date field during submission : https://jira.duraspace.org/browse/DS-672
[20:09] <mhwood> Should not NPE, that's for sure.
[20:09] <sandsfish> do we have a standard solution/library for javascript validation of fields?
[20:09] <tdonohue> Any volunteers to verify & perhaps resolve DS-672
[20:09] <sandsfish> jQuery or the like?
[20:09] <mhwood> Give it to me. I hate NPEs.
[20:10] <tdonohue> jQuery is in some XMLUI themes (Mirage, I believe) -- but not in JSPUI
[20:10] <tdonohue> ok, assign DS-672 to mhwood for testing & analysis.
[20:10] <tdonohue> (although, if we wanted, this could be a nice opportunity to "standardize" on jQuery validation -- worth possibly looking at, mhwood, if it helps)
[20:10] <sandsfish> it would be great to have a standard way to validate & give immediate UI feedback. (just sayin')
[20:11] <sandsfish> yup
[20:11] * tdonohue and sandsfish said same thing
[20:11] <tdonohue> ok..next one
[20:11] <tdonohue> My Archived Submissions : https://jira.duraspace.org/browse/DS-673
[20:12] <tdonohue> I do recall, that JSPUI has this feature, and XMLUI does not
[20:12] <tdonohue> and..bonus, there's a patch already! Anyone want to volunteer to review the work, and maybe commit it if it looks good?
[20:13] <PeterDietz> it looks like the RC for 1.7 forgot to notice this one
[20:13] <tdonohue> (Fyi -- since this patch adds new i18n tags, it'd likely have to wait to be released till 1.8.0, as we generally don't release language pack changes in .1 releases)
[20:15] <tdonohue> No volunteers? Ok, I'll do it then. :) Assign DS-673 to tdonohue for code review & possible commit for 1.8
[20:15] <tdonohue> Add and Remove Selected actions on individual metadata fields have an effect on the whole form : https://jira.duraspace.org/browse/DS-674
[20:16] <tdonohue> DS-674 seems like another area the something like jQuery could potentially be helpful (rather than reloading the whole page)
[20:17] <PeterDietz> I think we need to work on a submissions API then
[20:17] <tdonohue> what are others thoughts here?
[20:17] <mhwood> The current behavior is incorrect and surprising.
[20:18] <tdonohue> what do you mean by "submissions API", PeterDietz? is this Java? Javascript?
[20:18] <PeterDietz> re: incorrect/surprising: especially if you checkmark a checkbox, then click next.. it deletes anything that was checkmarked
[20:18] <tdonohue> ugh
[20:19] <tdonohue> PeterDietz, is this something you all are working on at OSU? I recall you mentioning you are doing usability work with submissions interfaces?
[20:19] <mdiggory> tdonohue: we don't release language pack changes?
[20:19] <mdiggory> they should be released asyncronously
[20:19] <mdiggory> 1.8.0.0, 1.8.0.1, 1.8.1.0
[20:20] <mdiggory> sorry s/8/7
[20:20] <tdonohue> mdiggory -- that's not what I said... we release changes, but we don't tend to *add new fields* in bug fix releases (or at least, again, we didn't with the 1.6.x cycle)
[20:20] <PeterDietz> tdonohue, to send a ajax request to update the form to hold the newly added field, and to save the state of the action "Add More" it would be nice to have an HTTP rest api to submit the newly added field... but alternatively some fancy ui things could allow you to keep the newly added field in the form, but add a warning that you have unsaved changes
[20:21] <mdiggory> sorry maybe I misunderstood.... tdonohue: (Fyi -- since this patch adds new i18n tags, it'd likely have to wait to be released till 1.8.0, as we generally don't release language pack changes in .1 releases)
[20:21] <tdonohue> mdiggory -- ok, maybe I did say that. I was "misquoted" :) I meant that we don't tend to add new fields to language packs in .1 releases
[20:21] <mdiggory> by *add new fields* your refering to db fields... correct?
[20:22] <mhwood> "New message catalog keys" is what I understood.
[20:22] <tdonohue> no -- I'm referring to adding brand new 'key=value' pairs in i18n. As soon as we add new i18n pairs, we break all our existing language packs in that area (i.e. we require updates to all"
[20:23] <mdiggory> I've never been under the impression that we couldn't add new fields to the language packs incrementally. Sounds like your referring to making code changes in 1.7.1 that would require new fields to be present in lang-packs
[20:23] <tdonohue> so, if we suddenly added 5 new catalog keys in 1.7.1, we'd have to make sure *all* of our existing language packs were updated to translate those keys. That's not really considered a "bug fix" in my opinion
[20:24] <mhwood> We need a standing "translators" team and some tools to help them know when there is work to be done.
[20:24] <mdiggory> so, in your opinion its a question of translation work.
[20:24] <tdonohue> mdiggory -- that's *exactly* what I was referring to. If you look at the context of my initial comments, I was talking about https://jira.duraspace.org/browse/DS-673 , which adds *new code* that *requires new catalog keys*
[20:25] <mdiggory> wheras, thats why I implemented the async release of lang packs, to enable incremental contributions
[20:25] <tdonohue> right, but what I'm saying is that we don't want to require our translators to retranslate every time we do a new .1 release. Because translation work takes time, we don't want it to break that easily
[20:25] <mdiggory> so, 1.7.0.1 may add fields... to which translators would contribute changes commited to that langpack trunk, and then released as 1.7.0.2
[20:26] <mdiggory> this was the original intent of the approach
[20:27] <mdiggory> thus an addition of a i18n field would be addresss incrementally by those in the community that needed it
[20:27] <mdiggory> and we would not waste time translating fields that were not actually used
[20:27] <mdiggory> or I mean... in languages that were not actually used
[20:28] <mhwood> I think there's objection to a "bug fix" that's fixed in some languages but not (quite) in others.
[20:28] <tdonohue> ok -- we've now taken this way off our path of JIRA discussions :) but that's OK. we can stop where we were (though DS-674 still needs a volunteer)
[20:28] <mdiggory> By utilizing the above approach, your inviting the community to participate in the translation process specifically where it is needed
[20:29] <mdiggory> were the translations even verified before 1.7.0 released?
[20:30] <tdonohue> mdiggory, I think I disagree though, mostly because currently we *don't* have tools to ease in translation (if we did, that'd be another matter). Personally, I'd like to see us stabilize (as much as we can) the i18n Keys during bug-fix releases, so that translators don't have to revisit past translation so frequently
[20:30] <tdonohue> mdiggory -- I think you are missing my point / or we are talking across each other
[20:30] <mdiggory> actually using JIRA and release cycles would be the best tool for facilitation
[20:31] <mdiggory> tickets to update the translations are most welcome.
[20:31] <tdonohue> mdiggory: translators are using JIRA -- the problem is more in terms of determining *what changed* in the i18n keys, and where the keys are now being used
[20:31] <mhwood> I think the disagreement here is over whether localizations *should* be asynchronous.
[20:31] <mdiggory> well, you can generate a report off the maven build that outlines the keys with translations that are missing.
[20:31] <PeterDietz> I'll take DS-674 I'm somewhat working on it.. We'll need to reach a consensus on lang issues.. otherwise I'll commit to 1.7.x with hardcoded values, and trunk with messages-lang keys
[20:32] <tdonohue> actually, not entirely -- I think they should be asynchronous, but only asynchronous in terms of making *improvements* to past translations. So, someone comes along and says that's a bad translation, and fixes it
[20:32] <tdonohue> ok, thanks PeterDietz -- assign DS-674 to PeterDietz
[20:32] <kshepherd> morning *, sorry for lateness
[20:33] <mdiggory> I guess I don't see why Peter can't do both in 1.7.x a sane hardcoded default stored in the i18n, a release of langpacks could parallel 1.7.1
[20:33] <tdonohue> but, if others disagree on the i18n issue, we can discuss/vote on it. This is just my opinion
[20:34] <mhwood> Is that localization skew report documented somewhere?
[20:35] <tdonohue> mdiggory: i didn't understand that last comment. The only thing I'm disagreeing about is adding *new code* to a 1.7.1 which suddenly requires *new i18n keys*. And, I'm only disagreeing, cause we've previously called 1.7.1 a "Bug-fix only" release, and I didn't consider this a "bug fix"
[20:36] <mhwood> 674 sounds like a bug to me.
[20:37] <mdiggory> mhwood: its part of the pom in dspace-api-lang, but not part of dspace-xmlu-api-lang
[20:37] <mdiggory> tdonohue: all good
[20:38] <tdonohue> ok..so, I guess we can continue? :)
[20:38] <mdiggory> mhwood: hmmm... sorry apparently that was commented out of the pom entirely
[20:38] <mdiggory> <!-- Breaks build because Messages.properties isn't stored here.
[20:38] <mdiggory>
[20:39] <mdiggory> ok... continue
[20:40] <tdonohue> ok. moving on for now. We can revisit i18n more if needed (i don't know if we came to an agreement there, or if that was just mdiggory and I not understanding one another)
[20:40] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[20:41] <tdonohue> a few announcements: 1.8.0 tentative timeline & (very) tentative feature listing are now up on: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes
[20:41] <tdonohue> If you have more features you are working on, please add to that list, or to JIRA (or both).
[20:42] <tdonohue> Also, I added a new "How To Contribute Ideas or Suggest New Features" section to this page: https://wiki.duraspace.org/display/DSPACE/HowToContribute This is meant as a reference for community members on how to put in requests for new features
[20:42] <mdiggory> tdonohue: just a difference of opinion there... lets keep moving
[20:42] <tdonohue> *comments/suggestions/changes/improvements are welcome* -- and you don't need to provide them now, feel free to take time to review and make changes/suggestions
[20:44] <tdonohue> Next general topic: Seems like the 1.7.x branch is getting some activity in SVN. Which likely implies a 1.7.1 sometime in the next month or so. Anyone have thoughts on that?
[20:44] <PeterDietz> as per: Make your request known to DSpace Developers, I think our habit has been to close jira tickets for new functionality without a patch
[20:44] <tdonohue> PeterDietz -- no, that's not correct actually. We have many open "feature requests" in JIRA
[20:45] <mhwood> No patch + we can't quite see what the poster is getting at + looming release date usually means postponement, not closure.
[20:46] <tdonohue> mhwood is right -- we postpone all the time. But, we only close requests if we think they are "off the wall" or don't understand the need at all.
[20:47] <tdonohue> Here's the list of all currently open New Feature requests: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+status+%3D+Open+and+issuetype%3D%22New+Feature%22+ORDER+BY+issuetype+DESC%2C+priority+DESC
[20:47] <mhwood> What's fixed in 1_7_x so far? Anything urgent enough to force release soon? Enough weight of less-urgent fixes?
[20:48] <stuartlewis> I have a fix to apply - in Item.java: https://jira.duraspace.org/browse/DS-806
[20:48] <tdonohue> From what I've seen so far, it looks like the 1.7.x fixes have been minor so far
[20:49] <tdonohue> and I was about to link to DS-806 too, but stuartlewis beat me to it. That's the only semi-major fix I've seen
[20:49] <mdiggory> Per 1.8.0 I think we need a concerted effort to begin to identify best practices for the architecture of new functionality in DSpace
[20:50] <tdonohue> mdiggory -- sounds good, but we need someone to lead the "concentrated effort" or kick us off with some proposed best practices. Could make for a good Special Topic meeting or two
[20:50] <mdiggory> This would basically be a list of do's and don't's
[20:51] <tdonohue> right mdiggory -- and someone needs to start that list, is all I'm saying, or propose that list (with examples when needed)
[20:51] <mdiggory> yes, I guess since I opened by big mouth... I've basically volunteered ;-)
[20:51] <tdonohue> yep :) assigned to mdiggory -- proposed best practices for new functionality, etc
[20:52] <mdiggory> I'm assuming I will create something round/about here
[20:52] <mdiggory> https://wiki.duraspace.org/display/DSPACE/HowToContribute
[20:52] <tdonohue> Any other thoughts on 1.7.1? stuartlewis, I'm assuming that you feel DS-806 would require a semi-quick release
[20:53] <tdonohue> mdiggory -- actually, better would be to create it around here: https://wiki.duraspace.org/display/DSPACE/ContributionGuidelines (that's the contribution guidelines for New Code)
[20:53] <PeterDietz> In that list would something like: new functionality would also have an associated test package src/test/java/org/dspace/package/NewFunctionalityTest.java
[20:53] <sandsfish> I'd like to see that JS validation included by 1.8.0. I'll try to look into that some. mhwood, lmk if you come across anything for your fix of that issue.
[20:53] <mdiggory> yes, expanding on https://wiki.duraspace.org/display/DSPACE/ContributionGuidelines
[20:53] <stuartlewis> Not necessarily. It seems a nasty little bug, but it has been there for many versions (ever since we added multiple metadata schema support I suspect) and no one has noticed it to date. So I don't think we need to rush out a release just for that.
[20:53] <stuartlewis> Having said that, I think we're getting the message that the community like to see a x.y.1 for confidence, so perhaps would be good to get one out sometime.
[20:54] <tdonohue> PeterDietz +1 -- I agree, we should make it best practice to start doing JUnit testing -- I've been bad about that as well
[20:54] <sandsfish> tdonohue: you and 80% of the developers in the world (myself included)
[20:55] <grahamtriggs> we either need to retrain the community, or just call our first beta x.y.0, so that the final release can be x.y.1
[20:55] <tdonohue> stuartlewis -- yea, even if DS-806 didn't necessitate quick release, it seems like we're starting to build up a set of small fixes worth putting out -- it's just a matter of whether we try to rush something out soon (in few weeks to a month) or wait for a while longer (2-3months?)
[20:56] <stuartlewis> Maybe sooner, so we can start working on 1.8 in earnest?
[20:56] <PeterDietz> in the web seminar tomorrow, I'm saying something about the caveat of waiting for 1.7.1, as there is the possibility of 1.8.0 happening before 1.7.1, in which case there would be no 1.7.1 being released
[20:56] <mhwood> 2mo. of fixes is probably enough for a x.y.1
[20:56] <tdonohue> well, we can do both simultaneously -- we have both 1.7.1 and 1.8 going now (in branch & trunk). I don't think we need to wait on 1.8 at all -- we can start now
[20:56] * mdiggory just created https://wiki.duraspace.org/display/DSPACE/DSpace+Architectural+Best+Practices
[20:57] <grahamtriggs> I suggest looking at a release end of Feb / start of Mar for 1.7.1 (little bit of time to get some more fixes), or not at all
[20:58] <tdonohue> ok. sounds like no one is in a rush. we could tentatively say we'll think about a 1.7.1 in late Feb / early Mar. I won't announce anything right now -- so, it could still be possible we'd not do a 1.7.1 unless we end up with a bigger issue, or lots of small ones we really want to push out
[20:59] <mdiggory> I'd recommend a release sometime around May to leave some room for further bugs to get caught
[20:59] <mdiggory> but prior to OR11 to be able to announce there
[20:59] <mhwood> Can always do 1.7.2 if needed.
[21:00] <tdonohue> mdiggory -- we'll just revisit in Feb & we can always change things then. the key here is that it sounds like we've found nothing significant so far which warrants an immediate 1.7.1
[21:01] <mdiggory> speaking of releases... will the community ever "decommission" a release from being supported, we seem to do that intrinsically by not doing any further minor releases on the previous major version.
[21:01] <tdonohue> Ok, noticing we're at time here. But, I wanted to ask. Thoughts on a Special Topic Mtg in next few weeks? Anyone have anything they'd like to discuss in more depth? Some "bigger topics" are listed in agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-26
[21:02] <tdonohue> mdiggory -- yea, that's never really been formalized, but we generally still offer support all the time on older releases (1.3.2 and the like) on dspace-tech. But, it's generally know that you are better off if you stick to more recent releases. We could formalize this though, if we wanted to
[21:02] <mhwood> Metadata cleanup, revamp, DCValue removal?
[21:03] <sandsfish> Ideas on Javascript Validation / AJAX back-end supporting classes? :)
[21:03] <sandsfish> (one-track mind)
[21:04] <kshepherd> i'll just note that while DS-785 / DSCR-11 might not be *urgent*, they might be showstoppers for users wanting to start trying Discovery out
[21:04] <PeterDietz> I'm always a proponent of DVCS/git. Also deprecated code like DCValue should be removed/replaced
[21:04] <kshepherd> so it'd be nice to have them fixed in a release kinda soon...
[21:04] <sandsfish> (that (validation) might be best on dspace-dev. i'll worry about it there.
[21:04] <sandsfish> +1 for the git conversation.
[21:05] <stuartlewis> +1 for the services/slf/sword problem being fixed in 1.7.1
[21:05] <tdonohue> ok, sounds like we have +2 for both Git & Metadata discussions soonish
[21:06] <mdiggory> sandsfish: AJAX work may also get precipitated in some of our client work... but we certainly welcome more hands in Mirage
[21:06] <tdonohue> kshepherd -- thanks for reminding of DS-785, that could be a bigger fix for a 1.7.1. Once it is fixed, feel free to suggest a 1.7.1 in very near future
[21:06] <kshepherd> sandsfish: i'm all for some nice ajax helper stuff, including validation, as long as we remember that it's client-side validation and so cannot ever be trusted ;) [in terms of security/server behaviour]
[21:07] <mdiggory> For @mire we need to be careful about the jquery versioning across our modules now that we've contributed the core library to dspace
[21:07] <mdiggory> stuartlewis: did you guys make any process on the slf issue?
[21:07] * jefftrimble (~jefftrimb@pool-70-20-65-250.pitbpa.east.verizon.net) Quit (Quit: Leaving)
[21:07] <mdiggory> process = progress
[21:07] <tdonohue> So, for a Git special topics meetings, I'd prefer if someone else led the meeting (looking around, towards OSU). I'm not very Git-savvy yet...so, when we schedule that is based on when someone else wants to lead it
[21:08] <sandsfish> ksheperd: noted, mdiggory: understood. i'm guessing as long as we work with the currently included version, things should be fine, yes?
[21:08] <kshepherd> mdiggory: no progress beyond what i've commented in JIRA... still a bit lost in the dspace services/kernel angle to it
[21:09] <PeterDietz> tdonohue, I'm happy to lead the git meeting, however, I can't lead next weekend, as have a conflicting baby-ultrasound
[21:09] <tdonohue> PeterDietz -- ok, maybe Feb 9 or Feb 16? It's up to you
[21:10] <tdonohue> PeterDietz -- you can always get back to me on that as well...no rush right now, would just like to get it scheduled
[21:10] <PeterDietz> both of those dates work for me.
[21:10] <PeterDietz> so perhaps the sooner the better
[21:10] <tdonohue> Ok -- let's say "Git Special Topic Mtg will be on Feb 9".
[21:10] <mdiggory> sandsfish Yea, we will adapt anytime theres improvement... we like to see it coming ;-)
[21:10] <sandsfish> will do.
[21:11] <tdonohue> Ok, we'll close up meeting. Feel free to continue discussions. I'll stick around for a while as well!
[21:11] <mdiggory> kshepherd: can you remind me of that ticket again...
[21:11] <kshepherd> mdiggory: https://jira.duraspace.org/browse/DS-785
[21:11] <kshepherd> mdiggory: and https://jira.duraspace.org/browse/DSRV-11
[21:12] <kshepherd> in subsequent testing, it seemed like other ingest methods would trigger it
[21:12] <kshepherd> rolling back slf4j versions fixed those, but sword still doesn't work for some reason
[21:13] <mdiggory> so does sword need slf4j 1.5.6?
[21:13] <tdonohue> By the way -- just saw a note from Jeff Trimble. If anyone is interested in joining an eventual 'Documentation Team' (helping manage/edit docs, but won't need to write them all, obviously), please get in touch with myself or Jeff. We'd like to get this team started ASAP.
[21:13] <kshepherd> mdiggory: it doesn't use slf4j at all, afaik
[21:14] <kshepherd> which confused me more.
[21:15] <kshepherd> so, after rolling back to 1.5.5, the issue might not be with slf4j at all. whatever the case, enabling the discovery event consumer means no sword deposits
[21:15] <kshepherd> i'll test more next week
[21:16] <mdiggory> so, it sounds like direct debugging in sword needs to happen to determine where the break occurs. Is sword even starting up, or is it in executing the Event Manager
[21:17] <kshepherd> mdiggory: see the last stack trace in DS-785 comments... probably means more to you than me! ;)
[21:18] <sandsfish> While I'm thinking about it, does anyone believe that requiring certificates on a user account should prevent them from using user/pass login via SWORD? We came across this the other day and it felt like a bug to me (considering there's no cert auth via SWORD possible).
[21:19] <mdiggory> Does sword use the authentication stack?
[21:20] <stuartlewis> Yes it does.
[21:21] <stuartlewis> brb - coffee time.
[21:21] <stuartlewis> (at least I'm 99% sure it does)
[21:21] <tdonohue> I thought SWORD cannot fully use the auth stack, as it only supports HTTP basic auth?? but, maybe I'm wrong?
[21:25] <mdiggory> kshepherd ok, smells like we really need unit testing on the individual webapps to be able to catch these issues before they happen in the future.
[21:25] <sandsfish> hm, ok, well it sounds at least like there's some questions to be answered. i'll try to dig a little deeper.
[21:25] <sandsfish> cheers all!
[21:25] <tdonohue> Yea, it looks like SWORD uses its own authenticator -- org.dspace.sword.SWORDAuthenticator
[21:25] * sandsfish braces for the ft. of snow that's starting to fall.
[21:25] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) Quit (Quit: sandsfish)
[21:28] <tdonohue> oh wait -- looks like I'm wrong. SWORDAuthenticator loads the DSpace AuthenticationManager and the auth stack.
[21:36] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:59] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[22:00] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[22:01] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (Read error: Connection reset by peer)
[22:01] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[22:18] * neanlos (~neanlos@190.144.163.85) Quit (Read error: Connection reset by peer)
[22:32] * ksclarke (~kevin@adsl-39-65-246.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[22:47] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) Quit (Quit: mdiggory)
[22:47] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[22:48] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[22:49] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Client Quit)
[22:50] * ksclarke (~kevin@adsl-39-65-246.clt.bellsouth.net) has joined #duraspace
[22:59] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[23:01] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) Quit (Quit: Page closed)
[23:58] * ianthe (~ianthe@cowu.be) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.