Timestamps are in GMT/BST.
[2:21] * awoods (~awoods@c-98-245-50-182.hsd1.co.comcast.net) Quit (Quit: Leaving)
[5:00] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[5:07] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 255 seconds)
[6:11] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[6:32] -sinisalo.freenode.net- *** Looking up your hostname...
[6:32] -sinisalo.freenode.net- *** Checking Ident
[6:32] -sinisalo.freenode.net- *** Found your hostname
[6:32] -sinisalo.freenode.net- *** No Ident response
[6:32] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:32] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:32] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:04] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 246 seconds)
[10:16] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[10:23] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 260 seconds)
[10:34] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[10:39] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 240 seconds)
[10:41] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[10:44] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:16] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:29] * dyelar (~dyelar@66.45.158.31) has joined #duraspace
[13:02] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:34] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[14:35] * cknowles (uid98028@gateway/web/irccloud.com/x-qjeeobfnbfowhtlx) has joined #duraspace
[14:59] * jcreel (~jcreel@nat-165-91-13-155.tamulink.tamu.edu) has joined #duraspace
[14:59] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) has joined #duraspace
[15:00] <tdonohue> Hi all. Welcome. It's our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-10-21
[15:00] <kompewter> [ DevMtg 2015-10-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-10-21
[15:01] <tdonohue> So, today, as in recent weeks, we're mostly scheduled to talk about 6.0 and 5.4
[15:02] <tdonohue> Before we get started though, I neglected to mention in today's agenda that I have a conflict with next week's DevMtg (Oct 28 @ 20:00 UTC). So, unfortunately, I'll be unable to attend that meeting
[15:02] * terry-b (~chrome@71-212-24-25.tukw.qwest.net) has joined #duraspace
[15:02] <tdonohue> I suspect through the course of today's meeting, we'll get a good sense of what next week's agenda should look like though.
[15:03] <tdonohue> And before the end of this meeting, I'll see if one of you can take the lead next week in my absence
[15:04] <tdonohue> But, we'll set that aside for now, and move on to our first topic for today: DSpace 6.0 & its timeline, etc
[15:05] <tdonohue> As pbecker noted in the agenda... The Pull Request Deadline for 6.0 is (very) rapidly approaching. In fact, it's one week from tomorrow
[15:06] <pbecker> In the last days I fixed versioning for JSPUI.
[15:06] <pbecker> Now I'm rebasing my PRs for the versioning feature.
[15:06] <tdonohue> This brings up an important question: Are we really going to be able to "meet" this deadline? While it seemed reasonable when the Service API refactor was initially merged, we've encountered some instability issues in the refactored API that have taken away from our ability to easily rebase all "broken" PRs
[15:06] <pbecker> I noticed that I mainly have to completly rewrite them as so much has changed.
[15:07] <pbecker> It is impossible for me to rebase all my PRs for the Deadline.
[15:07] <pbecker> I can say today, that I won't make this deadline and ask for more time.
[15:08] <hpottinger> (we should note that our RC, Andrea Schweer, cannot attend this meeting due to the timing of it)
[15:08] <tdonohue> I'll also note that rebasing my PR to add Reloadable Configs (via Apache Commons Config) also has taken forever. It's now *finally* passing Unit Tests, but still isn't working correctly in the new API.
[15:08] <tdonohue> hpottinger: aschweer is RC for 5.4...not for 6.0
[15:08] <hpottinger> heh, true, for now
[15:08] <pbecker> hpottinger: always pushing? ;-)
[15:10] <tdonohue> So, I guess my question is... what do we feel we should do about the PR deadline? It seems unlikely that all our 6.0 PRs will be rebased in time. Do we give individual PRs extensions, or do we push the deadline back?
[15:10] <hpottinger> hmm... it sounded like pbecker said "I'd like to be RC for 6"
[15:10] <peterdietz> I have S3 assetstore, which needs to be refactored still. And I wanted to contribute SAML auth, but I'm nervous that it might add too much complexity to a UI... That perhaps just leave that as a recipe of here's how to wire this yourself...
[15:11] <peterdietz> ..since I don't think I could wire it super clean (just change this 1 config) in time
[15:11] <tdonohue> Currently, we still have 59 PRs which are flagged as "merge conflict". Guaranteed, some of these are old PRs which likely won't even be considered for 6.0 (as they are outdated anyway). But, it gives you an idea of the scale of this: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+label%3A%22merge+conflict%22
[15:11] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+label%3A%22merge+conflict%22
[15:12] <tdonohue> 24 PRs are flagged as both "merge conflict" and under consideration for 6.0: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+label%3A%22merge+conflict%22+milestone%3A6.0
[15:12] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+label%3A%22merge+conflict%22+milestone%3A6.0
[15:12] <pbecker> I don't like the idea of giving some PRs more time. That just reduces the time to review and merge those.
[15:12] <pbecker> I think we need more time as hard as that is regarding the final release date.
[15:14] <tdonohue> Just for context, here's our current tentative release timelines: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-ReleaseTimeline
[15:14] <mhwood> Yes, I think we have to accept that the schedule must slip. Services API is taking longer to finish up than we expected, due to the amount of other code affected.
[15:14] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-ReleaseTimeline
[15:15] <tdonohue> So, what seems like a good option? Do we push back a week, two weeks, a month? I'd hate to push too far back, but at the same time, I realize the scope of this problem is a bit unique (first major API refactor we've *ever* done)
[15:16] <mhwood> Not less than two weeks, I think.
[15:16] <pbecker> mhwood++
[15:16] <tdonohue> I'd agree that one week seems too small. I'd hate to push back a full month... but 2-3 weeks might work
[15:16] <pbecker> I have at seven PRs to rebase. The first is almost done.
[15:17] <pbecker> s/have at/have
[15:17] <kompewter> pbecker meant to say: I have seven PRs to rebase. The first is almost done.
[15:17] <mhwood> Anyone want to argue for 3 rather than 2?
[15:17] <pbecker> I'm glad about every day I can get.
[15:18] <tdonohue> Two weeks would push the deadline to Thus, Nov 12. Three weeks would be Thurs, Nov 19
[15:19] <tdonohue> Do we think Nov 12 is doable...it's three weeks from tomorrow? I feel it'd work for me. But, I want to be sure others feel comfortable with that over Nov 19
[15:20] <hpottinger> any more and you're edging into US holiday season
[15:20] <tdonohue> Honestly, speak up here if you really thing 3 weeks is needed. Otherwise, I think I'm leaning towards just extending by 2 weeks
[15:20] <tdonohue> s/thing/think/
[15:20] <kompewter> tdonohue meant to say: Honestly, speak up here if you really think 3 weeks is needed. Otherwise, I think I'm leaning towards just extending by 2 weeks
[15:20] <pbecker> I hope I can do it in to more weeks. Three would be better.
[15:21] <pbecker> Let's say to more weeks ans if need one more for previously selected PRs. Is that fine?
[15:21] <pbecker> s/ans/and
[15:21] <kompewter> pbecker meant to say: Let's say to more weeks and if need one more for previously selected PRs. Is that fine?
[15:21] <tdonohue> Anyone else have opinions here? Or does this really only affect pbecker & I?
[15:22] <tdonohue> pbecker: I think it's reasonable to provide exceptions for specific PRs. We just would want them to not take *too* much longer obviously :)
[15:22] * tdonohue notes this seems like a quiet group today :)
[15:23] <peterdietz> I've got a nebulous several weeks amount of time I would want.
[15:23] <mhwood> I think we're all waiting to see if anyone has a strong opinion. :-)
[15:24] <hpottinger> 2/3 weeks, either runs into my vacation at the end of the month, I'll need to get cracking on the few PRs I've been considering
[15:24] <tdonohue> Ok, sounds like we go with 2 weeks then. The new PR deadline will be Thurs, Nov 12. If in the next week or so we realize we need to push to Nov 19, we can do so.
[15:24] <pbecker> sounds good!
[15:24] <peterdietz> If one hasn't developed something by now, then they shouldn't try to stuff it in, in the next 3 weeks, postpone that for dspace.next (7)
[15:26] <tdonohue> After this meeting, we'll do some more 6.0 PR reviews in the JIRA backlog hour. We'll try and keep this a normal thing for PRs which are already "waiting"
[15:26] <tdonohue> So, the only other topic under 6.0 that I have on the agenda was DS-2030, added by pbecker
[15:26] <kompewter> [ https://jira.duraspace.org/browse/DS-2030 ] - [DS-2030] Remove IP address based session hijacking protection - DuraSpace JIRA
[15:27] <pbecker> I just wanted to get some attention on this ticket.
[15:27] <tdonohue> pbecker is there specific quick feedback you wanted here? Did you just want approval to move forward with this idea?
[15:27] <mhwood> It seems reasonable to me.
[15:28] <pbecker> I would like to remove our current IP-Based session hijacking mechanism. I think it is not a good one and tomcat already contains better ones.
[15:28] <pbecker> I just want to know if there are objections against completely removing it without any replacements?
[15:28] <tdonohue> It seems reasonable to me too... the code you are talking about removing is ancient (from 1.5 days, or earlier).
[15:29] <pbecker> In XMLUI it is configurable, but I would remove it as well. I do consider this as bad practice.
[15:29] <tdonohue> My only request would be that we might want to document (or link to) *how* to achieve this same idea in Tomcat, for folks who still want it. That way there's a "replacement" for this old, outdated code
[15:30] <pbecker> tdonohue: I don't know if it is achievable in tomcat at all. But if you're googling about it, you find many comments that say "don't do it, bad idea, use better mechanisms to detect session hijacking)
[15:30] * jcreel (~jcreel@nat-165-91-13-155.tamulink.tamu.edu) Quit (Quit: jcreel)
[15:30] <tdonohue> I'm fine with removing the code / config entirely
[15:30] <hpottinger> I think Tomcat "just does this" on it's own, there is lots of that kind of thing built into Tomcat7 now
[15:30] * jcreel (~jcreel@nat-165-91-13-155.tamulink.tamu.edu) has joined #duraspace
[15:31] <pbecker> hpottinger: exactly, that's why I would silently remove it.
[15:31] <tdonohue> ok, pbecker. Wasn't sure if there was anything else special since you mentioned "tomcat already contains better ones"... I didn't know if you were referring to a special setting
[15:31] <hpottinger> pbecker: if you see anything about session fixation protection (like resetting a sessino after login) let me know?
[15:31] <pbecker> hpottinger look at the link in one of the comments.
[15:32] <pbecker> I haven't read it completely, but I noticed it was showing out that tomcat 7 does something in exactly that direction.
[15:32] * pbecker notices that he haven't linked it.
[15:32] <tdonohue> In any case, I think this old code should just be removed. If there's any relevant notes about Tomcat, we should add those.
[15:32] <pbecker> hpottinger: I'll send you a mail, please ask me again in case I forget to do so.
[15:33] <pbecker> thanks. :-)
[15:33] <tdonohue> Is that all the feedback you needed on 2030 then? Sounds like we all agree to remove it
[15:34] <pbecker> that's it. I'll create a PR in time for the deadline. ;-)
[15:34] <pbecker> (should be really simple)
[15:34] <tdonohue> Are there any other topics folks need/want to discuss that relate to DSpace 6.0?
[15:35] <hpottinger> reason I was asking is DS-570, I have a suspicion we may have some old session fixation attack prevention code somewhere
[15:35] <kompewter> [ https://jira.duraspace.org/browse/DS-570 ] - [DS-570] Redirect users to current page on login - DuraSpace JIRA
[15:36] <pbecker> just for the log and hpottinger ;-): "Session fixation protection is turned on by default in all Apache Tomcat 7 versions and from Apache Tomcat 6.0.21 on." (source: http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection)
[15:37] <tdonohue> pbecker: nice. Please add that link to your 2030 ticket too :)
[15:38] <mhwood> I think that only applies when having the container manage authentication? Which we do not.
[15:38] <hpottinger> mhwood is correct
[15:38] <pbecker> tdonohue: https://jira.duraspace.org/browse/DS-2030?focusedCommentId=45924&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-45924
[15:38] <kompewter> [ [DS-2030] Remove IP address based session hijacking protection - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2030?focusedCommentId=45924&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-45924
[15:38] <kompewter> [ https://jira.duraspace.org/browse/DS-2030 ] - [DS-2030] Remove IP address based session hijacking protection - DuraSpace JIRA
[15:38] <pbecker> mhwood: good point.
[15:39] <tdonohue> aha. ok
[15:39] <tdonohue> So, in the essence of time, is there anything else to discuss about this today? It seems like this may just need more investigation "offline" (post-meeting)
[15:40] <mhwood> Everybody seems to think that we can do better than this old code.
[15:40] <tdonohue> yep. ok, moving along then to other topics
[15:40] <hpottinger> pbecker, when you have a PR, ping me, I'll test
[15:40] <pbecker> I would say let us remove this old code now. Let us create a ticket to add some better stuff separately.
[15:41] <pbecker> hpottinger: great!
[15:41] <tdonohue> The DSpace 5.4 release. As decided in last week's meeting, the 5.4 release is tentatively scheduled for the first week in November. The goal here is to fix any major outstanding 5.x bugs (obviously)
[15:42] <tdonohue> I added this to the agenda mostly to touch base. Are there any updates or specific issues to discuss regarding 5.4?
[15:43] <tdonohue> I know DS-2788 is still sitting around. cwilper are you aware of any updates to that ticket from @mire?
[15:43] <kompewter> [ https://jira.duraspace.org/browse/DS-2788 ] - [DS-2788] Performance degradation of SOLR Discovery indexing in DSpace 5 - DuraSpace JIRA
[15:43] <tdonohue> I'm essentially just wanting to ensure 2788 seems like its still possible to resolve by early November. Many of our other tickets scheduled for 5.4 have PRs
[15:45] <tdonohue> Regarding 5.4, I'll also mention DS-2823, which could use additional "eyes" / testers. It's a tiny change, but at least for me, it seems significant (and obvious, since Discovery *used* to limit to 10K tokens in the index)
[15:45] <kompewter> [ https://jira.duraspace.org/browse/DS-2823 ] - [DS-2823] Discovery doesn't let you LIMIT the size of full text indexed, which can cause memory issues. - DuraSpace JIRA
[15:46] <hpottinger> Lucene used to, yes?
[15:46] <tdonohue> Lucene did, yes. But, so did the initial version of Discovery. It was only when we upgraded Discovery to Solr 4 that this setting "disappeared"
[15:47] <hpottinger> Oh, huh
[15:47] <tdonohue> And that happened in DSpace 4.0. So, DSpace 4.0 through 5.3 indexes the *entire text* of documents... but <DSpace 4.0 just indexes the first 10,000 tokens (words)
[15:47] <hpottinger> so, the Solr schema counts as "configurable enough"?
[15:48] <hpottinger> just thinking some institutions might want to retain the choice to "play chicken" with their fulltext indexing
[15:49] <mhwood> Actually that's in solrconfig.xml, not schema.xml.
[15:49] <tdonohue> no, it's in the schema.xml actually
[15:49] <hpottinger> ah, yes, good point, mhwood
[15:49] <tdonohue> look at the PR: https://github.com/DSpace/DSpace/pull/1120
[15:49] * hpottinger is confused, goes to look
[15:49] <kompewter> [ DS-2823: Limit Solr text field size to 10,000 tokens by tdonohue · Pull Request #1120 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1120
[15:50] <hpottinger> OK, so... schema.xml counts as local config option
[15:50] <tdonohue> I think as long as we document how to *change* this, it is ok to put in the schema.xml. Our tendency to try to stuff everything in dspace.cfg is not very "scalable" long term.
[15:51] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 240 seconds)
[15:51] <hpottinger> we'll just have to "keep on our toes" when it comes to merging changes from upstream, is all, the schema.xml changes from time to time
[15:52] <mhwood> I think we could put this in a .properties and do conditional substitution in solrconfig.xml?
[15:53] <hpottinger> look at mhwood speaking favorably of .properties ;-)
[15:53] <mhwood> <filter class='blah' maxTokenCount='{10000:customMaxTokenCount}' or some such.
[15:53] <tdonohue> Not sure what the suggestion here is, and whether this is worth spending so much time on today. This setting needs to get into the *schema.xml* one way or the other. Either we "filter" it into there, or we just set it in there and tell people how to change it
[15:54] <mhwood> Not filtering at build time; Solr will do substitution at startup.
[15:54] <mhwood> We can talk about it later.
[15:54] <tdonohue> mhwood: yea, send me notes or a PR on that. I didn't realize Solr could do that, I guess
[15:54] <hpottinger> I personally like the idea of shipping software that has a good chance of surviving no matter what data you throw at it, but some people might disagree
[15:55] <tdonohue> Ok, any other updates on 5.4 here? We're running very short on time :)
[15:56] <tdonohue> Ok, hearing none...we'll move along
[15:56] <tdonohue> The next topic on the agenda. The DSpace UI Prototype Challenge: https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[15:56] <kompewter> [ DSpace UI Prototype Challenge - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[15:57] <tdonohue> I just wanted to note here that the *deadline* for this challenge will likely be extended (currently at Nov 6) because of the conflicts in timelines with 6.0 (& 5.4)
[15:57] <tdonohue> Still working though on what the new deadline would be...but it may be more like end of Nov / early Dec (early guess)
[15:58] <tdonohue> An announcement will be forthcoming though, obviously
[15:58] <tdonohue> If you have any strong opinions/suggestions on this, you are welcome to ping me on it. I'll be working with the UI Working Group to get the new deadline set & announced
[15:58] <tdonohue> That's all I really wanted to say on that..but questions are welcome
[16:00] <tdonohue> Beyond that, we're nearly out of time here, so I'm not going to bring up any additional topics today
[16:00] <tdonohue> Any final thoughts from anyone or questions? (if not, the meeting will be closed shortly)
[16:01] <pbecker> I just created DS-2825.
[16:01] <kompewter> [ https://jira.duraspace.org/browse/DS-2825 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[16:01] * jcreel (~jcreel@nat-165-91-13-155.tamulink.tamu.edu) Quit (Quit: jcreel)
[16:01] <pbecker> I restricted the visibility of this ticket.
[16:02] <pbecker> Would be great if you would take a look on it and discuss whether we can and should make tomcat 8 a requirement for DSpace 6 or 7.
[16:02] <pbecker> Tomcat 8 is required to implement Session Fixation in DSpace.
[16:03] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[16:03] <tdonohue> pbecker: thanks for the note
[16:03] <hpottinger> I'm not a big fan of implementing session fixation preventing in DSpace
[16:03] <hpottinger> Tomcat 7 includes it already
[16:04] <tdonohue> We'll go ahead and close up the meeting for today (additional session fixation discussions can happen ad hoc or in tickets). If you'd like to join us in #dspace, we'll be doing some 6.0 PR reviews for the next hour (anyone who can make it)
[16:04] <pbecker> hpottinger: but as mhwood noted only if you use the login mechanism of tomcat.
[16:05] <mhwood> I can do reviews for a while, but will have to leave around 1640UTC.
[16:08] <hpottinger> pbecker, I'm moving to #dspace
[16:10] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 255 seconds)
[16:21] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[16:27] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 250 seconds)
[16:38] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[16:44] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 256 seconds)
[16:55] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[17:03] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 260 seconds)
[17:14] * airborn (~airborn@unaffiliated/airborn) has joined #duraspace
[17:19] * airborn (~airborn@unaffiliated/airborn) Quit (Ping timeout: 240 seconds)
[17:24] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:33] * cknowles (uid98028@gateway/web/irccloud.com/x-qjeeobfnbfowhtlx) Quit (Quit: Connection closed for inactivity)
[19:32] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[19:46] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[20:02] * cknowles (uid98028@gateway/web/irccloud.com/x-cukhsbuvdbyfgehc) has joined #duraspace
[20:57] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:02] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:40] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
[23:03] * cknowles (uid98028@gateway/web/irccloud.com/x-cukhsbuvdbyfgehc) Quit (Quit: Connection closed for inactivity)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.