Timestamps are in GMT/BST.
[0:56] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Remote host closed the connection)
[0:57] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[1:01] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 264 seconds)
[2:44] * Disconnected.
[2:44] -hobana.freenode.net- *** Looking up your hostname...
[2:44] -hobana.freenode.net- *** Checking Ident
[2:44] -hobana.freenode.net- *** Found your hostname
[2:44] -hobana.freenode.net- *** No Ident response
[6:33] -leguin.freenode.net- *** Looking up your hostname...
[6:33] -leguin.freenode.net- *** Checking Ident
[6:33] -leguin.freenode.net- *** Found your hostname
[6:33] -leguin.freenode.net- *** No Ident response
[6:33] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:33] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:33] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:58] * bollini (~chatzilla@193.206.99.195) has joined #duraspace
[12:16] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:50] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[12:56] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[12:59] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:00] * hpottinger needs tea, brb
[13:01] <hpottinger> back, are we doing this thing? :-)
[13:01] <mhwood> I am.
[13:02] <bollini> )'m here too
[13:02] <hpottinger> Yay! /endKermitMode
[13:02] <bollini> someone remember where we have stopped in PR review?
[13:03] <hpottinger> looking for the transcript now
[13:03] <tdonohue> I'm just lurking. Won't be able to contribute much likely. We left off though at #202, I believe
[13:03] <mhwood> Still under discussion.
[13:05] <hpottinger> '[21:23] <tdonohue> On Friday though you'd start at #205 (or #202 if you want to touch on it more)'
[13:05] <bollini> I suggest to skip over... NOT for 4.0, so to check if that hurt someone
[13:05] <hpottinger> list is here: https://docs.google.com/spreadsheet/ccc?key=0AimboW73gZRJdEVkdUdxR2Nac0JqeXA1QmRBcmlRbHc#gid=0
[13:05] <kompewter> [ Google Docs - Online documents, spreadsheets, presentations, surveys, file storage and more ] - https://docs.google.com/spreadsheet/ccc?key=0AimboW73gZRJdEVkdUdxR2Nac0JqeXA1QmRBcmlRbHc#gid=0
[13:06] <hpottinger> bollini: skip over? re: 202, or 205?
[13:06] <bollini> 202
[13:07] <hpottinger> I'm OK with skipping/not4-ing 202
[13:08] <mhwood> Yes, it seems to be part of a larger effort to sort out our overall l10n design.
[13:09] <bollini> ok, #205 good to merge I can get it
[13:09] <hpottinger> so, we just have the RT here and tdonohue plus a few other lurkers, correct?
[13:10] * l_a_p (~chatzilla@ru-dirgarrlan-ru-bk-dir.dir.garr.it) has joined #duraspace
[13:10] <bollini> mmm... we don't have send any email about this meeting
[13:11] <hpottinger> You're correct, bollini, though it was the topic of the last few minutes of the previous meeting
[13:11] <pbecker> it was part of the last developer meeting and of the irclog.
[13:11] <bollini> so I think that we should move fast on the pr list
[13:12] <hpottinger> bollini++
[13:12] <bollini> make some decision to share publicly so to raise objection / suggestion
[13:12] <bollini> we have a list of pr that are not ready to merge, just check if we have a member of RT able to work on it
[13:13] <hpottinger> one sec, I'm at home, a dog is begging to be let out, brb
[13:14] <hpottinger> back
[13:14] <bollini> for the PR that are mergeable check if there are any objection and if no, prioritize, propose a merge date hopeful before the feature freeze
[13:14] * fasseg (~fas@HSI-KBW-095-208-193-241.hsi5.kabel-badenwuerttemberg.de) has joined #duraspace
[13:15] <hpottinger> I have a similar proposal: if a PR is just waiting for a final check, and one of us agrees to check it, we can pre-approve the merge?
[13:15] <bollini> hpottinger++
[13:16] <hpottinger> so, the "in 4.0?" column would have 3 values: yes, no, and provisionally
[13:16] <pbecker> I rebased pr #295, should be mergable again. As I don't see the merge button, I didn't want to change its status in the google docs table. can anyone please confirm its mergable now?
[13:17] <hpottinger> I see a green button, and Travis agrees
[13:17] <pbecker> thank you hpottinger.
[13:18] <bollini> hpottinger: I will prefer yes/no/more review needed
[13:19] <bollini> hpottinger: if only a check is required from one of us I want to put Yes and if thing go wrong we can raise an exception
[13:19] <hpottinger> bollini: OK, so maybe Yes, pending?
[13:20] <hpottinger> or Yes, pending review?
[13:20] <bollini> so the three values are?
[13:21] <hpottinger> yes, no, yes-pending-review
[13:21] <hpottinger> the column isn't populated at all at the moment, anyway :-)
[13:22] <bollini> ok, try to say in a different way
[13:22] <bollini> I want to be clear with the original contributor
[13:22] <bollini> No mean we don't thing that there is any chance to get this in
[13:23] <bollini> Yes, we are confident to be able to get this in without external help (only RT involved)
[13:23] <bollini> the third option is we are like to see that in but we are not able to do that without help
[13:24] <hpottinger> OK, yeah, yes/no are the only values required, we can just use notes column to indicate which ones are pre-approved to merge after review
[13:24] <bollini> ok, go ahead with that
[13:24] <hpottinger> next: 222?
[13:25] <bollini> yes, I can check
[13:25] <mhwood> So, [scrolling way, way back] did we approve 205?
[13:25] <bollini> 205: +1
[13:26] <mhwood> 205 +1
[13:26] <bollini> it was also discussed in a previous meeting with general consensus
[13:27] <hpottinger> 205 +1
[13:27] <bollini> 205: YES | pre-approved to merge (we have +3)
[13:27] * fasseg (~fas@HSI-KBW-095-208-193-241.hsi5.kabel-badenwuerttemberg.de) has left #duraspace
[13:27] <bollini> 222: yes, +1 from me
[13:28] <hpottinger> I don't think I'd use it, but have no objections, and it's clean to merge, 222: yes, +1
[13:29] <mhwood> There are two CAS plugin PRs
[13:30] * hpottinger thought that sounded familiar
[13:30] <bollini> mhwood: yes, this is related to the recent version of CAS 3.x / I can check it
[13:30] <mhwood> I had them both on my todo list.
[13:31] <bollini> do you want check yourself?
[13:32] <mhwood> I could do both, or we could split them between us.
[13:32] <hpottinger> just 38 more to go! :-)
[13:33] <bollini> I have add me as review on 222
[13:33] <bollini> do we have a +3 after my review? is pre-approved?
[13:33] <mhwood> Yes, we need CAS. I'll look at #186 then.
[13:33] <bollini> ok
[13:34] <bollini> 222: YES | pre-approved to merge
[13:34] <bollini> https://github.com/dspace/dspace/pull/229
[13:34] <kompewter> [ Updated SWORDv2 module by richard-jones · Pull Request #229 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/229
[13:35] <bollini> mhwood: I have assigned the PR 186 to you
[13:36] <hpottinger> 229: Richard is rebasing the PR to work with current master, will let us know when he's ready
[13:36] <mhwood> I would say 229 is well reviewed. Richard Jones elsewhere said he'd work out the issues mentioned by Tim.
[13:37] <bollini> Ok, so add yes and put a note waiting new rebased PR
[13:37] <hpottinger> +1
[13:37] <mhwood> +1
[13:37] <hpottinger> *and* we make Richard push the merge button :-)
[13:37] <bollini> I want just remember you that I'm not familiar with google doc so please update it
[13:38] <hpottinger> I'll update the doc later today, unless someone beats me to it
[13:38] <bollini> hpottinger: thanks
[13:39] <hpottinger> speaking of google docs, when the document stabilizes, I'd like to move it to the DuraSpace wiki
[13:39] <hpottinger> probably put it on the 4.0 Release Notes page
[13:39] <bollini> yes, it will be better
[13:42] <hpottinger> 230: I'm not sure I'm following the discussion
[13:42] <bollini> yes. I'm looking to the code too
[13:42] <hpottinger> we have two senior committers scratching their heads over the code...
[13:44] * l_a_p (~chatzilla@ru-dirgarrlan-ru-bk-dir.dir.garr.it) Quit (Read error: Connection reset by peer)
[13:45] <hpottinger> I'd feel better if one of them were in the room, tdonohue are you available to comment on PR 230?
[13:45] <bollini> I still thing that it was a bug in data
[13:46] <bollini> our code looks correct
[13:46] <bollini> dcv.schema MUST be something like 'dc'
[13:46] <bollini> there are no reason to allow a lookup by namespace
[13:46] <hpottinger> also, bollini: can you keep doing the ###: [YES|NO] \| thing? that'll help me later
[13:46] <mhwood> I think "Sometimes DSpace looks up a schema by the long namespace, and not the short name" means that either it should not do that, or there should be two methods.
[13:47] <mhwood> Probably it should not do that, and we should find out why it is happening, not patch around it.
[13:47] <bollini> mhwood: I'm looking to the changes and its not make sense
[13:48] <hpottinger> two methods seems a sensible proposal
[13:48] <bollini> we have two method in MetadataSchema to perform the lookup
[13:48] <bollini> the change is about a private method in Item
[13:48] * hpottinger should refrain from commenting on code he's not actually looking at :-)
[13:49] <hpottinger> 36 rows to go!
[13:49] <bollini> I propose to set NO | Please provide sample data to reproduce the issue if we are wrong
[13:49] * fasseg (~fas@HSI-KBW-095-208-193-241.hsi5.kabel-badenwuerttemberg.de) has joined #duraspace
[13:50] <hpottinger> +1 NO, need more info
[13:50] <bollini> ...and I'm going to close the PR
[13:50] <mhwood> Yes. There is much confusion here. We should understand it before we try to fix it.
[13:50] * fasseg (~fas@HSI-KBW-095-208-193-241.hsi5.kabel-badenwuerttemberg.de) has left #duraspace
[13:51] <hpottinger> hmm... PR 230 didn't have a Jira issue attached, did it?
[13:51] <mhwood> If a DCValue is arriving with a schema named by namespace, it's wrong. That is what should be fixed.
[13:51] <mhwood> I did not find any link to an issue, no.
[13:51] <hpottinger> that's reason enough to reject the PR
[13:52] <bollini> already closed ;-)
[13:52] * hpottinger is a stickler for that rule
[13:52] <bollini> https://github.com/DSpace/DSpace/pull/232
[13:52] <kompewter> [ [DS-1456] "dspace version" command-line script by mwoodiupui · Pull Request #232 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/232
[13:52] <hpottinger> I like 232
[13:52] <hpottinger> so I'm +1 for merge
[13:52] <mhwood> Well, obviously I am +1 on this. :-)
[13:53] <hpottinger> I'm also +1 for mhwood doing the merge
[13:53] <mhwood> I would have liked to see some discussion of the approach, but I guess everyone finds it satisfactory.
[13:53] <bollini> I remember that we have add some discussion about the use of database table
[13:53] <bollini> but as we are approaching the feature freeze I'm +1 with that
[13:53] <bollini> please only check if there are issue with the slf4j dependencies
[13:54] <hpottinger> we did discuss the approach, I think we ran off into the weeds a bit
[13:54] <bollini> 232: YES | pre-approved to merge
[13:54] <hpottinger> ty bollini
[13:55] <bollini> https://github.com/DSpace/DSpace/pull/244
[13:55] <kompewter> [ DS-1648 1) DSpace enhancement, mapping author names to registered users with UI options 2) Keeping UI option to choose autor-user wise Collections where the item can be mapped. by alapchari · Pull Re[...] ] - https://github.com/DSpace/DSpace/pull/244
[13:55] <bollini> I'm -1 with that because need further discussion
[13:56] <mhwood> Yes, I see unresolved issues here.
[13:57] <bollini> 244: NO | Need further work
[13:57] <bollini> https://github.com/DSpace/DSpace/pull/246
[13:57] <kompewter> [ [DS-1212] Export all collections of a community recursively in ItemExport by zuki · Pull Request #246 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/246
[13:58] <hpottinger> assume no comment from me means I'm reading like a madman
[13:59] <bollini> hpottinger: I'm going ahead on 244 because we need to scream the list and I'm actually -1 (veto) about that other that there are some discussion still open in the PR
[14:00] <hpottinger> I agree with bollini's comment on PR246, that it's crossing scope with the AIP backup/restore
[14:00] <hpottinger> 244 decision is fine by me
[14:01] <hpottinger> I'm just saying I'll follow your decisions, if I disagree, I promise to do so quickly
[14:02] <mhwood> The whole export mechanism is an alternative to half of AIP. Some sites use one and some the other, yes?
[14:02] <bollini> I think so
[14:02] <bollini> I'm not sure about the implication of a change in the export content
[14:02] <hpottinger> well, export is available via the UIs
[14:02] <bollini> as someone can use it to import in a copy
[14:03] <bollini> and changing the content of the export could break such mechanism
[14:03] * tdonohue is back now..sorry, got pulled away for a bit
[14:03] <mhwood> If we support both at this time then it sounds like this should be fixed. If we want to steer people toward AIP then we should schedule deprecation of the mechanisms we want to replace.
[14:04] <bollini> but in the simple export there are no way (I'm guesting) to say that an item is in a particular collection
[14:04] <hpottinger> import/export is a simple thing on the UI-side, keeps repo admins happy and busy, I don't mind letting them play, and expanding what they can do without getting a developer involved is always a win in my book
[14:04] <mhwood> So, some people think "export a collection" means export the collection and its' sub-collections, and some do not? Then the new behavior should be optional?
[14:05] <hpottinger> I think what we're seeing here is this PR needs more discussion before merge
[14:05] <bollini> sorry
[14:06] <bollini> it is about export of a COMMUNITY
[14:06] <mhwood> Yes, more discussion.
[14:06] <mhwood> Yes, I got tangled up. Reading too fast.
[14:06] <bollini> so I have not objection, no way it could create issue to other in import
[14:06] <bollini> you can't use the export result to import in a community so it is only to make external processing
[14:07] <bollini> the content of a community is the content of all collections at any depth level
[14:07] <bollini> this is how browse and search work
[14:07] <hpottinger> I think it's a nice feature, and will make my repository admins happy
[14:07] <bollini> so my vote here is +1
[14:07] <mhwood> So all issues with this are addressed?
[14:08] <hpottinger> +1 for merge of 246
[14:08] <mhwood> It seems like this is the way it should have worked. If all objections are withdrawn, +1
[14:08] <tdonohue> I'm fine with #246. It sounds like a bug fix to me.
[14:08] <bollini> 246: +3, I'm doing the merge now
[14:09] <hpottinger> ooh, ty, bollini!
[14:09] <hpottinger> push the button, Max!
[14:09] <bollini> wait
[14:09] <bollini> I will push it at the end of the meeting
[14:09] <hpottinger> :-) ok
[14:09] <bollini> I wan't create any conflict with pr that we need to review
[14:09] <bollini> that can change the green button
[14:10] <hpottinger> sensibility reigns supreme
[14:10] <bollini> it add few message i18n
[14:11] <bollini> can we proceed for 30minutes/1hour again?
[14:11] <hpottinger> this is the *only* thin on my agenda today, and I get to work at home, so, yep, as long as we need
[14:11] <mhwood> I have nothing scheduled today. Yes.
[14:12] <tdonohue> I'm around now & free
[14:12] <bollini> 248 251 253 254 are bugs
[14:12] <hpottinger> well, OK, truthfully, I was hoping to test PR196 today
[14:12] <bollini> https://github.com/dspace/dspace/pull/260
[14:12] <kompewter> [ DS-824 Request copy of item for XMLUI by muelle · Pull Request #260 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/260
[14:13] <tdonohue> #260 = dirty
[14:13] <tdonohue> #260, #266 and #287, all unmergeable
[14:13] <bollini> probably it should be only rebased
[14:14] <bollini> someone from the xmlui side want to help with 260?
[14:15] <tdonohue> needs a volunteer / someone to rebase, or at least someone to request it be rebased
[14:15] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[14:15] <bollini> hpottinger / mhwood ? I'm not available for this
[14:16] <hpottinger> my plate is full
[14:16] <bollini> we can also mark it as NO
[14:16] <mhwood> Sorry, had to take a call. Looking at 260 now.
[14:16] <tdonohue> I suggest we just add a comment to #260 asking for someone to rebase this so that it's mergeable again.
[14:16] <hpottinger> I suggest we do the same for all "dirty" PRs
[14:16] <tdonohue> hpottinger +1
[14:16] <bollini> tdonohue: yes, but if we don't have someone in RT to check it we put no in the excel
[14:17] <tdonohue> bollini, that's fine.
[14:18] <bollini> ok, I have add a comment to the PR
[14:18] <pbecker> I would like to rebase it, but I don't no if I have time for it next week. Would you reconsider it after a rebase?
[14:18] <bollini> 260: NO | need rebase
[14:18] <pbecker> s/no/know
[14:18] <kompewter> pbecker meant to say: I would like to rebase it, but I don't know if I have time for it next week. Would you reconsider it after a rebase?
[14:18] <bollini> pbecker: yes
[14:18] <pbecker> thanks
[14:18] <mhwood> Yes, it sounds as though that is all that is left to do.
[14:18] <hpottinger> 10/21 is the feature freeze
[14:18] <hpottinger> you have 10 days
[14:19] <bollini> less please :-)
[14:19] <bollini> https://github.com/dspace/dspace/pull/266
[14:19] <kompewter> [ [DS-1188] Collection view doesn't show content by default by KevinVdV · Pull Request #266 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/266
[14:19] <pbecker> okay, I'll try
[14:19] <hpottinger> yes, if you expect a heroic merge, you'll need to work that out with a committer
[14:19] <bollini> not mergeable
[14:20] <bollini> 266: NO | Need rebase
[14:20] <hpottinger> 287: bollini can you get this one in?
[14:20] <bollini> yes, I'm doing the rebase but there are issue with the new solr
[14:20] <bollini> I'm trying to solve
[14:21] <bollini> can I have pre-approved after the rebase?
[14:21] <tdonohue> I'd be +1 #287 once it is mergeable
[14:21] <mhwood> Yes.
[14:21] <hpottinger> let us know if we can help, I don't have any objections for 287
[14:22] <bollini> ok thanks
[14:22] <bollini> 287: YES | pre-approved after solving merge conflict / issue
[14:22] <bollini> https://github.com/dspace/dspace/pull/291
[14:22] <kompewter> [ See https://jira.duraspace.org/browse/DS-1644 by terrywbrady · Pull Request #291 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/291
[14:23] <mhwood> +1
[14:23] <hpottinger> 291 is a bug fix?
[14:23] <mhwood> I've already been working with him on this. It seems ready. Yes, a bug fix.
[14:23] <tdonohue> yea we don't need to review all bug fixes right now...in essence of time, we can skip them until later
[14:24] <tdonohue> 291 seems ok to me too, but we should concentrate on new features
[14:24] <bollini> ok, +1 I will press the green button at the end of the meeting
[14:24] <hpottinger> I'm ok with any committer merging any bug fix they are confident in
[14:24] <bollini> https://github.com/dspace/dspace/pull/294
[14:24] <kompewter> [ [DS-1647] Adds MetadataWebService curation task by richardrodgers · Pull Request #294 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/294
[14:25] <hpottinger> 294 is a nice feature, I see no problem with adding a curation task to the collection of curation tasks
[14:25] <tdonohue> #294 seems ok to me. Just needs some docs on how to use it.
[14:25] <mhwood> 294 seems well made, but I'm not sure I understand how it would be used. That says more about my understanding than about the use.
[14:26] <bollini> I'm assignee on 294, I want to check if there are issue with the http library
[14:26] <hpottinger> +1 pre-approved to merge 294
[14:26] <bollini> so I propose pre-approved after a fast check
[14:26] <mhwood> Oh, yes. We probably should have an issue to comb out the older versions of that library.
[14:26] <mhwood> +1 294
[14:26] <tdonohue> +1 294. Definitely needs some docs though
[14:26] <bollini> 294: YES | pre-approved merge after check
[14:27] <bollini> tdonohue: there is documentation on the richard repo, we need to put it in the official one
[14:27] <bollini> https://github.com/dspace/dspace/pull/295
[14:27] <kompewter> [ DS-1637 Support running handle server and application container on separate machines (2nd version) by tuub · Pull Request #295 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/295
[14:28] <bollini> +1 with that (I'm worked with pbecker and I'm using a back porting to dspace 1.6 of that in production)
[14:29] <hpottinger> good enough for me +1
[14:29] <tdonohue> #295: again needs docs. Not sure how to use this exactly. But it "sounds" OK.
[14:29] <mhwood> +1
[14:30] <bollini> ok, I will merge at the end of the meeting. I will add a note to my todo about documentation (pbecker: please help)
[14:30] <pbecker> I'll help with documentation
[14:30] <hpottinger> 297: bug fix, skip
[14:31] <bollini> https://github.com/dspace/dspace/pull/299
[14:31] <kompewter> [ DS-1656 New Input-Type Constant and attribute Maxlength for input-forms.xml by jpiscanc · Pull Request #299 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/299
[14:32] <mhwood> Seems like two features.
[14:32] <bollini> mmm it is in conflict with the new look and feel
[14:33] <tdonohue> #299: It is two features. Both seem reasonable to me. But, code is slightly messy. There's a ton of "// DS-1656" comments riddled through the code, and very odd spacing / gaps.
[14:33] <kompewter> [ https://jira.duraspace.org/browse/DS-1656 ] - [#DS-1656] New Input-Type Constant and attribute Maxlength for input-forms.xml - DuraSpace JIRA
[14:33] <bollini> with the new look and feel the input size is maximized to the available space
[14:34] <tdonohue> by "new look & feel" do you mean the new JSPUI look & feel?
[14:34] <bollini> https://github.com/dspace/dspace/pull/321
[14:34] <kompewter> [ [DS-1675] New JSPUI look & feel by lap82 · Pull Request #321 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/321
[14:34] <bollini> tdonohue: yes, #299 is for jspui
[14:35] <tdonohue> bollini: no, #299 is both jspui and xmlui
[14:35] <bollini> tdonohue: ohhh sorry not noted
[14:36] <tdonohue> but, you are correct, the JSPUI part might conflict with your #321
[14:36] <tdonohue> In any case, with #299 I think we need some minor code cleanup & possible testing alongside #321 before we can accept
[14:36] <mhwood> bollini, could you work with the author of 299 on this?
[14:37] <hpottinger> hmm... maybe merge 321 first, and then help with rebase of 299?
[14:37] <mhwood> A little advice should move this forward.
[14:37] <bollini> 299 not make sense with the new look and feel
[14:37] <hpottinger> (after we discuss 321, of course :-)
[14:37] <mhwood> The JSPUI part of the MaxLength part doesn't make sense after 321. The rest?
[14:37] <bollini> anyway I will work with the author to make some cleanup and better understanding (also not sure about the need of a constant - we have item template)
[14:38] <bollini> constant should be item template
[14:39] <tdonohue> I also added a comment to #299 about needing some code cleanup. So, I think we set #299 aside until we also review #321.
[14:39] <mhwood> That sounds sensible.
[14:39] <bollini> ok, go ahead
[14:39] <bollini> https://github.com/dspace/dspace/pull/301
[14:39] <kompewter> [ [DS-1667] Remove deprecated LoadDSpaceLNIConfig servlet by mwoodiupui · Pull Request #301 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/301
[14:39] <hpottinger> 301: bug fix?
[14:40] <tdonohue> 301 is a bug fix. Looks like an obvious "merge immediately" though
[14:40] <hpottinger> but, no objections from me about fixing bugs
[14:40] <mhwood> Not really fixing anything except dead code.
[14:40] <bollini> yes, merge immediatly
[14:40] <mhwood> Done!
[14:40] <hpottinger> Yay! like we used to do!
[14:41] <bollini> https://github.com/dspace/dspace/pull/303
[14:41] <kompewter> [ Single search box by rivaldi8 · Pull Request #303 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/303
[14:42] <bollini> +1 with that
[14:42] <hpottinger> 303 is fine by me
[14:42] <tdonohue> #303: +1 I've always disliked having the search box appear twice on the homepage. This removes the one in the body.
[14:42] <bollini> 303: YES | at the end of meeting
[14:43] <bollini> https://github.com/dspace/dspace/pull/304
[14:43] <kompewter> [ DS-1234 by jpiscanc · Pull Request #304 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/304
[14:43] <mhwood> Yes to the concept. Is the question of *which* search box settled and implemented?
[14:43] <tdonohue> mhwood: yea, #303 removes the search box in the body of the page, and leaves the one in the sidebar.
[14:43] <tdonohue> #304: Travis CI says the build fails. Needs work
[14:43] <mhwood> OK, as long as all issues are addressed, +1
[14:44] <bollini> 304: NO | build error
[14:44] <mhwood> Commit messages also need work....
[14:44] <hpottinger> 304: re DS-1234
[14:44] <kompewter> [ https://jira.duraspace.org/browse/DS-1234 ] - [#DS-1234] Edit an Item using the workflow process - DuraSpace JIRA
[14:44] <bollini> please stay in our rule about excel :-)
[14:44] <hpottinger> :-) oh, sorry
[14:44] <bollini> https://github.com/dspace/dspace/pull/305
[14:44] <kompewter> [ DS-1536 having a DOT in handle prefix causes identifier.uri to be cut of... by rivaldi8 · Pull Request #305 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/305
[14:45] <tdonohue> 305: bug fix.
[14:45] <bollini> right
[14:45] <bollini> https://github.com/dspace/dspace/pull/306
[14:45] <kompewter> [ [DS-1252] Integrate external bibliographic services in DSpace submission process by lap82 · Pull Request #306 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/306
[14:45] <bollini> Ok, about that
[14:46] <bollini> I have talked with kostas
[14:46] <bollini> we think that our solution should reuse the work from BTE
[14:47] <bollini> so we are checking if we can easly introduce an adapter to embed BTE in the submission lookup
[14:47] <bollini> can we skip that and leave for the next meeting?
[14:47] <hpottinger> are you all withdrawing 306?
[14:47] <mhwood> So this one is not quite ready.
[14:47] <tdonohue> sure, makes sense to skip 306 until ready to discuss
[14:47] <bollini> just to be clear 306 is ready and working
[14:48] <bollini> but it introduces a different framework to make crosswalking
[14:48] <bollini> there is no need to keep in place two different solution, configuration and documentation
[14:48] <tdonohue> well, either way, 306 is not ready to discuss/approve, since it's being changed
[14:48] <bollini> https://github.com/dspace/dspace/pull/307
[14:48] <kompewter> [ DS-1677 While registering a specified identifier IdentifierServiceImpl doesn't check if an IdentifierProvider supports it by tuub · Pull Request #307 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/307
[14:48] <mhwood> Yes.
[14:48] <pbecker> PR 307 is a bug fix, but one needed for pr 312 and probably 308.
[14:49] <hpottinger> I really want 306 in 4.0, so hit me up if you need my +1
[14:49] <bollini> +1 merge immediatly
[14:49] <pbecker> thanks
[14:49] <mhwood> 307 already +1 from me
[14:49] <tdonohue> 307 is a bug fix, but it does look like a good one
[14:49] <bollini> mhwood: can you push?
[14:50] <pbecker> no
[14:50] <mhwood> It is pulled.
[14:50] <hpottinger> we are rocking it today
[14:50] <bollini> pbecker: no, what?
[14:51] <hpottinger> 14 to go
[14:51] <bollini> https://github.com/dspace/dspace/pull/308
[14:51] <kompewter> [ [DS-1678] EZID DOI provider by mwoodiupui · Pull Request #308 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/308
[14:51] <pbecker> sorry, wrong windows
[14:51] <pbecker> everything fine, thanks for merging 307. :-)
[14:51] <bollini> 308: +1 from me
[14:52] <mhwood> Clearly +1 from me.
[14:52] <pbecker> I think it would be greate to have support for EZID and DataCite. But should we really need to add to IdentifierProvider?
[14:52] <mhwood> Wait for 312 as suggested?
[14:53] <bollini> there will be some issue with httpcomponent
[14:53] <hpottinger> +1 for 308, and mhwood, pick the appropriate merge order
[14:53] <pbecker> s/to/two
[14:53] <kompewter> pbecker meant to say: I think it would be greate two have support for EZID and DataCite. But should we really need to add to IdentifierProvider?
[14:53] <bollini> 308: YES | take caution about httpcomponent version
[14:53] <tdonohue> 308: I think I'm still confused about the differences between this and DS-1535. But, as long as they both work together well and don't create duplicative configs/settings, it sounds good.
[14:53] <kompewter> [ https://jira.duraspace.org/browse/DS-1535 ] - [#DS-1535] DOI support for dspace-api - DuraSpace JIRA
[14:54] <mhwood> There are (at least) two services for coining DOIs at DataCite: their own and EZID.
[14:54] <bollini> tdonohue: they are alternative. Two different DOI providers
[14:54] <mhwood> Different APIs.
[14:54] <pbecker> I wrote 312 in a way that should make it easy to reuse my code while adding support for other registration agencies.
[14:54] <mhwood> I don't understand "But should we really need to add to IdentifierProvider?"
[14:55] <pbecker> mhwood: could you please take a look on org.dspace.identifier.doi.connector?
[14:55] <pbecker> I ment to say: should we really add two DOIIdentifierProviders.
[14:55] <tdonohue> ok. fine by me. Just needs some better docs about how to choose and configure
[14:55] <bollini> ok go ahead
[14:56] <hpottinger> Not to interrupt the flow, but I just got goosebumps thinking about everything going into 4.0
[14:56] <bollini> 308: YES | pre-approved to merge (caution about http component version)
[14:56] <bollini> https://github.com/dspace/dspace/pull/309
[14:56] <kompewter> [ Output policy data to METSRIGHTS only if a policy is effect (by date) by terrywbrady · Pull Request #309 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/309
[14:56] <bollini> hpottinger: :-)
[14:56] * tdonohue notes the next big challenge is gonna be ensure we have *docs* for all these things going into 4.0 ;)
[14:57] <mhwood> I will take a look at connector.
[14:57] <pbecker> mhwood: great :-) You would get the asynchronous stuff with not much work and we would have only one doiidentifierprovider.
[14:58] <pbecker> mhwood: if you have questions or need help: send me a mail
[14:58] <mhwood> There is only one. Mine is now EZIDIdentifierProvider. But I will look at connector.
[14:59] <pbecker> mhwood: it should be easy to reuse code from the EZIDIdentifierProvider to write a EZIDConnector. I just don't have the time and I even could not test it....
[14:59] <tdonohue> 309: seems OK to me. Does make me wonder if we also need to do something on import of METSRIGHTS in AIPs (to reset the policy date as needed).
[15:01] <bollini> 309: +1 too
[15:01] <mhwood> 309: helix84 has reviewed. To the extent I understand it, this seems sensible.
[15:01] <mhwood> +1
[15:01] <bollini> tdonohue: can you check after the meeting and report an issue if need (as you are the AIP expert)?
[15:01] <hpottinger> 309 +1
[15:02] <bollini> 309: YES | merge at the end of meeting (I'm taking note)
[15:02] <bollini> https://github.com/dspace/dspace/pull/310
[15:02] <kompewter> [ DS-1680 Handle user using the back button to change collection during ingest by gmh04 · Pull Request #310 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/310
[15:02] <hpottinger> on 309, do we need to wait for tdonohue's word on that?
[15:02] <tdonohue> bollini: to clarify, I think 309 is good (+1). Just wonder if eventually we want to restore on import too. Not sure I'm gonna have a chance to look at this in the near future (my dev time is extremely rare these days)
[15:03] <bollini> tdonohue: yes, I understand. Anyway it is right to export and... it could be an isssue on the import side
[15:03] <mhwood> 310 is a bug fix.
[15:04] <hpottinger> 310 bug fix, skip
[15:04] <bollini> https://github.com/dspace/dspace/pull/312
[15:04] <tdonohue> 309: clarifying again. There would be *no* issue/bug on the Import side. Just noting that it adds some new info to the exported AIP. Currently that new info in the exported AIP would just be "ignored" on import.
[15:04] <kompewter> [ DS-1535: DOI support for dspace-api by tuub · Pull Request #312 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/312
[15:04] <mhwood> tdonohue: file a JIRA issue on import concerns?
[15:04] <tdonohue> I'll add a comment on it
[15:05] <bollini> tdonohue: if import ignore some info it is a bug from my point of view
[15:05] <hpottinger> +1 Jira issue, so we don't lose it
[15:05] <bollini> tdonohue: this mean that can be fixed later before or after 4.0
[15:05] <tdonohue> not confident this is an issue yet, I'll ask creator of #309 first.
[15:05] <bollini> ok, so rollback
[15:06] <bollini> 309: YES | after check with creator
[15:06] <tdonohue> 309 also needs a JIRA ticket, I think
[15:06] <bollini> 312 has been already discussed
[15:07] <pbecker> I started the documentation (linked in jira), but I think I'll need help with the documentation as I'm not a native english speeker.
[15:07] <hpottinger> tdonohue is right, 309 doesn't have a Jira issue
[15:07] <mhwood> I can review documentation. I'll have to be writing some for 308 as well.
[15:07] <tdonohue> I'll add a comment to 309
[15:08] <bollini> ok thanks
[15:08] <pbecker> mhwood: thanks.
[15:08] <bollini> https://github.com/DSpace/DSpace/pull/312
[15:08] <kompewter> [ DS-1535: DOI support for dspace-api by tuub · Pull Request #312 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/312
[15:09] <bollini> it is ok for all yes after 308?
[15:09] <mhwood> Yes, we should have both.
[15:10] <bollini> 312: YES | see 308
[15:10] <bollini> https://github.com/dspace/dspace/pull/314
[15:10] <kompewter> [ [DS-1683] Add spell checker to discovery by KevinVdV · Pull Request #314 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/314
[15:11] <tdonohue> 314: +1 from me
[15:11] <bollini> I'm +1 with that, but I want to ask for an extension to port to the jspui
[15:11] <mhwood> Sounds like a reasonable thing to want, even though personally I despise automagical spell checkers.
[15:12] <bollini> extension mean that I (or l_a_p) will produce a PR for jspui before 10/21
[15:12] <bollini> mhwood: it is not automagical
[15:12] <bollini> screen here: https://jira.duraspace.org/browse/DS-1683
[15:12] <kompewter> [ [#DS-1683] Add spell checker to discovery - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1683
[15:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1683 ] - [#DS-1683] Add spell checker to discovery - DuraSpace JIRA
[15:13] <hpottinger> 314 +1 do we need to wait for feature parity?
[15:13] <mhwood> I guess an *additional* PR on the same issue qualifies as meeting the PR deadline....
[15:13] <bollini> hpottinger: no, we have drop feature parity
[15:14] <hpottinger> I'd say 314 is ok to merge now, and bollini you have my blessing to slip in a feature parity PR for JSPUI
[15:14] <bollini> good thanks
[15:14] <tdonohue> no need to wait for feature parity. we don't promise that anymore. Though I'd be fine with an "extension" to allow someone to create a PR to port to JSPUI
[15:14] <bollini> 314: YES | pre-approved merge
[15:14] <bollini> https://github.com/dspace/dspace/pull/316
[15:14] <kompewter> [ Create Spatial Index and Spatial Query by bbkopsas · Pull Request #316 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/316
[15:16] <bollini> -1, as it is for lucene and we need to understand better the requirement and how to make this work in solr
[15:16] <mhwood> Looks like nice work, but there's been zero discussion? Is there a ticket?
[15:16] <hpottinger> is 316 complete?
[15:16] <mhwood> bollini please comment the PR when you have time?
[15:17] <bollini> mhwood: ok
[15:17] <bollini> 316: NO | Need discussion
[15:17] <tdonohue> 316 seems like 1/2 a feature. It modifies Lucene to allow you to search, but I don't see any UI changes, so I don't understand how it works
[15:17] <mhwood> Is there a JIRA ticket?
[15:17] <hpottinger> 316 is missing a Jira issue, and the notes indicate more work is required
[15:17] <tdonohue> 316 also needs a JIRA ticket
[15:18] <bollini> ok noted to add as comment
[15:18] <bollini> https://github.com/dspace/dspace/pull/317
[15:18] <kompewter> [ [DS-1686] Support new version of Biblio-Transformation-Engine for the batch import by kstamatis · Pull Request #317 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/317
[15:18] <bollini> I'm assignee on that. +1
[15:18] <hpottinger> 317 looks ready to go
[15:19] <mhwood> Documentation.
[15:19] <tdonohue> yes, needs documentation.
[15:20] <mhwood> +1, ask for documentation update.
[15:20] <tdonohue> 317: Looks like the licensing issues with BTE were fixed though. So, just needs docs. +1
[15:21] <hpottinger> 317 +1
[15:21] <bollini> ok I have added a comment to the pr
[15:22] <bollini> 317: YES | pre-approved to merge
[15:23] <bollini> https://github.com/dspace/dspace/pull/318
[15:23] <kompewter> [ [DS-1688] Add UI support for BTE batch metadata import by kstamatis · Pull Request #318 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/318
[15:23] <hpottinger> 318: ooh, a UI for 317
[15:24] <bollini> hpottinger: yes
[15:24] <tdonohue> 318: Looks to be JSPUI only. Would be nice to find someone to do a port to XMLUI too. But, I'm +1 as long as it doesn't conflict with new JSPUI redesign
[15:25] <bollini> I propose to skip and discuss to the next meeting
[15:25] <bollini> I want to better understand overlapping with the new submission system
[15:25] <tdonohue> ok, we can skip and discuss next week
[15:26] <mhwood> OK
[15:26] <hpottinger> ok
[15:26] <bollini> https://github.com/dspace/dspace/pull/319
[15:26] <kompewter> [ [DS-1687] Porting Item Versioning to the JSPUI by lap82 · Pull Request #319 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/319
[15:26] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[15:26] <hpottinger> UI code is available if anyone needs it
[15:26] <bollini> hpottinger: UI code for what? XMLUI?
[15:27] <hpottinger> 318: jspui, if someone really wanted it, they could merge it to their own fork
[15:27] <tdonohue> 319: it's a port of an existing feature. Sounds good. (Again though, need to see how this affects JSPUI redesign work)
[15:28] <tdonohue> 319: Needs docs update though for the "enabled" config added to versioning.cfg
[15:28] <bollini> 318, 319 can be included in the JSP UI redesign (we can care of that, just we need to pick the right order)
[15:28] <bollini> is it needed? I'm talking about the enabled config
[15:29] <tdonohue> bollini: I don't know. Just noticed a new config there that would need documentation. If it's not needed, then it should be removed. The comment says "Enabled is only used for JSPUI"
[15:29] <hpottinger> (btw, Terry Brady just updated PR 309 with a JIRA issue)
[15:30] <bollini> tdonohue: I'm talking about real use case. We don't have a turn off option for xmlui, do we want it for jspui?
[15:30] <bollini> we can suggest / note to add documentation or ask to remove it
[15:31] <tdonohue> bollini: you actually *can* disable versioning from appearing XMLUI. You would just comment out the "Versioning" aspect. I.e. do the opposite of this: https://wiki.duraspace.org/display/DSDOC3x/Item+Level+Versioning#ItemLevelVersioning-EnablingItemLevelVersioning
[15:31] <kompewter> [ Item Level Versioning - DSpace 3.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC3x/Item+Level+Versioning#ItemLevelVersioning-EnablingItemLevelVersioning
[15:31] <bollini> tdonohue: ok sorry I don't knwo
[15:32] <bollini> so mark for need docuemtnation update
[15:32] <bollini> 319: YES | pre-approved merge
[15:32] <bollini> https://github.com/dspace/dspace/pull/320
[15:32] <kompewter> [ DS-1690 assign DSpace group based on LDAP attribute value by helix84 · Pull Request #320 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/320
[15:32] <mhwood> That's a common pattern: JSPUI uses a configuration switch and XMLUI is managed by commenting out the rendering.
[15:33] <bollini> I have still 30minute before leave
[15:33] <bollini> s/30/20/
[15:33] <kompewter> bollini meant to say: I have still 20minute before leave
[15:33] <hpottinger> I still have all day :-)
[15:34] <mhwood> 320 seems a sensible request.
[15:34] <bollini> can you take care of the merge? I'm not able to test
[15:35] <hpottinger> 320 looks fine, from a committer
[15:35] <bollini> oh yes it is form helix
[15:35] <bollini> +1
[15:35] <hpottinger> +1 trusted developer is trusted
[15:35] <bollini> 320: YES | pre-approved merge
[15:36] <bollini> https://github.com/dspace/dspace/pull/321
[15:36] <kompewter> [ [DS-1675] New JSPUI look & feel by lap82 · Pull Request #321 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/321
[15:37] <bollini> I have add some screens to allow simple review
[15:37] <bollini> https://jira.duraspace.org/browse/DS-1675
[15:37] <kompewter> [ https://jira.duraspace.org/browse/DS-1675 ] - [#DS-1675] New JSPUI look & feel - DuraSpace JIRA
[15:37] <kompewter> [ [#DS-1675] New JSPUI look & feel - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1675
[15:38] <tdonohue> wow!
[15:38] <bollini> it actually requires only to be turned on by default...also because there is no alternative
[15:38] <bollini> as no alternative I mean that the old theme as not been ported to bootstrap
[15:39] <mhwood> Quite attractive, and I like what I see about the work on the internals.
[15:39] <tdonohue> So, essentially this would require all current JSPUI sites to migrate their UI
[15:39] <bollini> it is not perfect but it is better than what we have now
[15:40] <bollini> yes...but old page look enough good in the new template
[15:40] <tdonohue> bollini: how easy is it to "theme"? For example, how easy is it for sites to change to match their local look & feel
[15:40] <bollini> this mean that some effect are not available as highlighting of input box, sizing, etc. but it still work and is readable
[15:41] <tdonohue> bollini: so, existing JSPUI sites would *not* be required to totally redo their existing JSPUI? It would still work?
[15:41] <mhwood> So, what is the smallest amount of work that an existing JSPUI site would have to do, to upgrade to DSpace 4.0 if this goes in?
[15:41] <tdonohue> I'm trying to understand the migration process here.. How hard is the upgrade to DSpace 4.0 for 3.x JSPUI users
[15:42] <bollini> theme is in the mean of css framework like jqueryui...you can very easly produce a css with different base color (there are UI for that)
[15:42] <bollini> migration depend on the amount of customization of course
[15:42] <tdonohue> (Cause I love the work you've done here... I want to see this get into 4.0, but I need to understand the upgrade process.)
[15:42] <bollini> you need to change the header to add your banner
[15:42] <hpottinger> :-) I feel sorry for bollini, two committers peppering him with the same question :o)
[15:43] <bollini> and you should clean your additional jsp but if you not do that it still work
[15:43] <hpottinger> here's a silly question for you: can one vary the theme based on collection/community, now?
[15:44] <mhwood> I can see an existing site saying, "we want that new look, but it can wait. How long to upgrade with our existing customized UI?"
[15:44] <bollini> actually not, but it is just matter of two code line in the tag library
[15:45] <bollini> customized jspui site need to wait also to upgrade to a "standard" dspace new version
[15:45] * terryb (~chatzilla@141.161.13.66) has joined #duraspace
[15:45] <bollini> customization is no matter of css actually in jspui
[15:45] <bollini> so no way to do that cleanly, you need to reapply your work
[15:45] <hpottinger> I'd consider jumping to JSPUI, this work looks that good, but only if I could continue to promise different themes to different constituencies.
[15:46] <mhwood> What I'm asking, I guess, is how much *more* work would this add to the upgrade?
[15:46] <bollini> hpottinger: I have decided to include in this pr only look and feel not redisign, so the theme for community/collection could be a (very easy and small) separate pr
[15:47] <bollini> I think that there are not difference in the migration path
[15:47] <hpottinger> bollini: if you can share that code with me, I can plan on pushing for the move to JSPUI
[15:47] <bollini> jspui customization requires lot of work
[15:48] <mhwood> If upgrading 3.x -> 4.0 takes X effort before this PR, then after this PR would it take 1.1 X? 2 X? 10 X?
[15:48] <hpottinger> I think mostly the question is: are we prepared to walk the community through the upgrade process?
[15:48] <bollini> exactly the same... I don't think that do any difference move a TR or move and change it to a DIV
[15:49] <tdonohue> I think we need to have some detailed docs here on the expected upgrade process from 3.x -> 4.0, especially for JSPUI sites which have little local customization. I'm assuming ones with major JSPUI customization will likely need to "start over" and redo their tweaks on the new UI?
[15:49] <bollini> we can provide documentation about how to edit navigation menu, move it to the left side, change the banner
[15:49] <hpottinger> in other words, I think my vote on 321 is +1: NEEDS DOCS :-)
[15:50] <bollini> the other thing are still matter of html there is no a dspace version not before this PR nor after
[15:50] <tdonohue> But, does this accidentally become a "barrier" to upgrade to 4.0 for sites which have major JSPUI changes? Or is it still a hard upgrade either way?
[15:50] <bollini> to talk about a real use case
[15:51] <bollini> for the HUB it is the same difficulties
[15:51] <bollini> http://hub.hku.hk/
[15:51] <kompewter> [ HKU Scholars Hub ] - http://hub.hku.hk/
[15:52] <bollini> when you have a hight customized jspui site most of time you are backporting new functionalities to your customization
[15:52] <bollini> you can still do that but you don't get the new look & feel really, or you ca redo your tweaks in the new UI
[15:53] <tdonohue> bollini: ok, that makes sense. What about for JSPUI sites with very little customizations then? It sounds like the 4.0 upgrade won't be too hard?
[15:54] <bollini> tdonohue: no it is a very simple and mechanic work to translate old html tag in the new ones
[15:56] <tdonohue> So, to clarify where I stand, I am definitely +1 this work. But, I'm trying to determine out best option... It seems like there are two directions we could take. (1) release this as the new JSPUI, completely replacing the old one, (2) OR, this becomes a third UI ("bootstrap UI" or something), and we immediately "deprecate" the old JSPUI in 4.0 and remove it entirely in 5.0.
[15:56] <mhwood> I think I'm convinced. Thank you.
[15:57] <bollini> tdonohue: have a separate webui on for the presentation layer could be very difficult to support (also for 1 year)
[15:58] <bollini> if an institution really want the old webui they only need to checkout the "previous" content of the webapp folder
[15:58] <hpottinger> my +1 is for replacing the current JSPUI (tdonohue's option 1)
[15:58] <mhwood> It sounds to me as though splitting JSPUI makes a lot of work for little.
[15:59] <tdonohue> yea, you could be right...maybe it's not worth the effort here
[15:59] <bollini> actually me and l_a_p are doing a last review and some minor tweaks (we are checking all the possible combination of features, like enabling embargo, creative commons, reordering step, controlled vocabulary, etc.)
[15:59] <mhwood> So, if this goes in, it should not go in just yet. Into 4.0 but not instantly.
[15:59] <tdonohue> I'm +1 either way. I just really wanted to note our options. I do think we need to have some detailed 4.0 upgrade/migration instructions for this new JSPUI though
[16:00] <hpottinger> I think the vast majority of JSPUI installations are just: pick JSPUI, put in a logo, maybe tweak the CSS... so, upgrade is just: move your logo, and re-tweak CSS
[16:01] <bollini> there is no much css to tweak in most case (you should download a css with your favourite color)
[16:01] <mhwood> +1
[16:01] <tdonohue> I'd rather we start to merge this soon. It's a bit "daunting" to have a massive PR sitting there where it cannot be easily tested by others. I think if we notice bugs / minor tweaks that are needed, those can come in later as separate bug-fix PRs
[16:01] <mhwood> True, we left time for that.
[16:01] <hpottinger> I agree +1 merge 321
[16:02] <bollini> what I mean with a final review was that we are ready, just wait one more day or two
[16:02] <tdonohue> bollini: ok, yea waiting a last day or two shouldn't matter much
[16:02] <bollini> the other question is, should we squash the history?
[16:03] <tdonohue> I'd also suggest we notify either dspace-devel or -commit about this soon (maybe even this week). It'd be nice to let others be well aware that this is coming, so they can chip in as needed and also make local preparations as they see fit
[16:03] <bollini> or is it fine to have a so hight number of commits? note that some are from me some from l_a_p so there is authorship issue in squashing
[16:03] <mhwood> I hesistate to do that. You lose useful boundaries sometimes. The larger a work, the more you may need to preserve how it came together.
[16:04] <tdonohue> mhwood++ leave the history as is. With a massive PR like this, I think the history is important
[16:04] <mhwood> I have no issue with large numbers of commits.
[16:04] <tdonohue> "squashing" makes much more sense for smaller more contained PRs
[16:04] <bollini> ok good
[16:05] <bollini> so the plan is, me and l_a_p will close the PR within the week
[16:05] <mhwood> I sometimes deliberately divide work into a sequence of commits so that it can be picked apart.
[16:05] <tdonohue> sounds good, bollini.
[16:05] <bollini> on sunday I will send an email to the devel and commit announcing the merge that if no issue will be performed on Monday
[16:05] <mhwood> Yes, thank you.
[16:06] <bollini> ok, for our excel
[16:06] <hpottinger> sounds good, bollini, thanks!
[16:06] <bollini> 321: YES | pre-approved to merge with notice to mailing list
[16:06] <mhwood> Before anybody has to go, I wanted to point out that we have some thinking to do about REST. From zero PRs we now have two, one that came in after the deadline, both quite recent.
[16:06] <tdonohue> sounds great!
[16:06] <hpottinger> mhwood: I thought we only had one PR for rest?
[16:07] <bollini> https://github.com/dspace/dspace/pull/323
[16:07] <kompewter> [ [DS-1696] DSpace REST API built in JERSEY by peterdietz · Pull Request #323 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/323
[16:07] <tdonohue> nope, we have two
[16:07] <tdonohue> #323 was under the deadline. #327 was just today
[16:07] <bollini> https://github.com/DSpace/DSpace/pull/327
[16:07] <kompewter> [ [DS-1695] Add SimpleREST, Restlet based api. by anis-moubarik · Pull Request #327 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/327
[16:07] <bollini> LGPL
[16:07] <bollini> travis error
[16:08] <hpottinger> oh, I missed 327, it's not on our list as I pulled it after the deadline but prior to 327
[16:08] <tdonohue> LGPL = ok. It's only GPL that is bad
[16:08] <tdonohue> https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions
[16:08] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions
[16:08] <tdonohue> Travis CI does give an error on #327 though
[16:09] <mhwood> Strictly by the rules, 327 missed the boat. But there's been little time to discuss either one.
[16:09] <hpottinger> 327: peterdietz had some concerns, mostly due to authZ
[16:09] <hpottinger> oh, look, there's PeterDietz lurking in the corner
[16:09] <bollini> yes authZ is not correctly implemented in 327
[16:10] <mhwood> At first glance I agree with that.
[16:10] <tdonohue> (minor note about #327. Travis CI is only complaining about invalid license headers.)
[16:11] <mhwood> So it looks as though 327 could not go in now even if we like it better, even if we relaxed the deadline.
[16:11] <bollini> I don't like to have a dspace webapp that use a license different than bsd
[16:11] <PeterDietz> hi all
[16:12] <hpottinger> 327 does support full CRUD, but I'm not sure we approve of the means it does so
[16:12] <bollini> one thing is to have a single internal dependencies or functionality but this is the "whole app"
[16:13] <hpottinger> hey, PeterDietz, we are weighing the relative merits of PR 323 and PR 327
[16:13] <bollini> a lgpl license for REST will mean that one that decide to rely only on the rest interface cannot make changes that are keep private
[16:14] <bollini> this is generally a good thing for open source but I'm worried about business opportunities
[16:14] <tdonohue> bollini: to clarify, we would have to re-license the SimpleREST under the DSpace BSD License in order to distribute it as our "own"
[16:14] <mhwood> I would really like to see a REST implementation in 4.0.
[16:14] <bollini> tdonohue: ok good
[16:14] <tdonohue> bollini: that's part of our Contribution Guidelines. We can have DSpace pull in third-party tools that use LGPL, or similar, but the DSpace codebase is *all* licensed BSD
[16:15] <mhwood> We have issues with 327. Do we have issues with 323?
[16:15] <PeterDietz> My biggest issue with simplerest is the auth portion. I guess you could resolve that by only logging the app in as anonymous user...
[16:15] <bollini> tdonohue: oops... forget about that. But as I write I'm heavy committed to BSD :-)
[16:16] <hpottinger> I have no issues with 323, it gets my +1
[16:16] <PeterDietz> My issues with 323 is that I've only addressed a short list of features/needs. i.e. I think people would like to have paging/limit/offset. And searching..
[16:17] <mhwood> Room to grow. Right now DSpace has nothing. Either of these is a lot more than that.
[16:18] <PeterDietz> I don't know if I'm partial/biased, but I think the code is clean enough, that any of us/you can modify it easily to accomplish that
[16:18] <tdonohue> I'd rather have "room to grow" than something that doesn't act how we think it should.
[16:18] <hpottinger> and any of those modifications could be considered "bug fixes"
[16:19] <bollini> any unit test?
[16:19] <mhwood> I doubt anyone can come up with a *complete* REST implementation without extensive field exposure. People will be thinking of new things they want to do for some time.
[16:20] <bollini> 327 look to have some unit test
[16:21] <bollini> I'm just trying to find differences that we can understand easily
[16:22] <tdonohue> 327 / SimpleREST seems a bit odd in it's AuthN (which PeterDietz rightly noted). It is always logged in as whatever user ID you set in your web.xml. Not sure how secure that is (or easy to setup for that matter)
[16:23] <PeterDietz> 323 I'm using JAXB to automate serialization (to JSON / XML). 327 uses Google GSON to output JSON, and does manual creation of xml rendering
[16:23] <bollini> I think that the licensing question need to discussed on 327 (we need to be sure that the National Library want to transfer ownership)
[16:23] <mhwood> 327 authn would need fixing.
[16:23] <tdonohue> automate > manual
[16:23] <hpottinger> manual XML... ow
[16:24] <bollini> we can allow some extra time to both to fix the issue / extend the features list and decide later
[16:24] <hpottinger> when do we decide?
[16:24] <PeterDietz> Regarding 327's support for (C) POST / (U) PUT / (D) DELETE. I guess its nice to have. But its parsing something that looks form generated, as in it might be parsing html input
[16:25] <tdonohue> So, 323 is less "feature-ful", but seems like a good base layer. 327 would need a license transfer, AuthN fixes, and some possible other code cleanup
[16:25] <hpottinger> ty tdonohue for putting it so succictly
[16:25] <tdonohue> I'm leaning heavily towards 323. I think it's fine if others want to build & maintain competing REST APIs (and we can always reserve the right to swap REST APIs later on)
[16:26] <mhwood> +1 323
[16:26] <hpottinger> I already voted, but here's my +1 323 again
[16:26] <tdonohue> +1 323
[16:26] <bollini> +1 on 323 is easy, it comes from peter trusted dev rule
[16:26] <PeterDietz> I'd like to vote, but I think according to ethics I need to abstain on this one...
[16:26] <mhwood> RT is unanimous.
[16:27] <bollini> ok, now I really need to leave
[16:27] * tdonohue logs publicly for the record that I owe PeterDietz a beer
[16:27] <mhwood> Thank you for staying so long.
[16:27] <bollini> 323: YES | pre-approved to merge
[16:28] <PeterDietz> Going forward, I'm going to be eyeing how Hedtek/Wijiti/SimpleREST implemented things, to either borrow or clean slate implementation
[16:28] <mhwood> 324 is a bug fix.
[16:28] <bollini> we left on the table two pr
[16:28] <bollini> one
[16:28] <mhwood> PeterDietz++
[16:28] <bollini> no!
[16:28] <bollini> I will stay
[16:28] <bollini> https://github.com/dspace/dspace/pull/324
[16:28] <kompewter> [ DS-1475 Improvement of Collection Dropdown by helix84 · Pull Request #324 · DSpace/DSpace · GitHub ] - https://github.com/dspace/dspace/pull/324
[16:28] <mhwood> No, 325 is bug fix, 324 is new
[16:28] <hpottinger> :-) that's the spirit!
[16:29] <bollini> try to close this review :-)
[16:29] <hpottinger> (and I think we *all* owe PeterDietz many, many beers)
[16:30] <PeterDietz> That should be a feature on a GitHub pull-request. Close, Comment, Accept, Give Beer
[16:30] <bollini> ok, I'm going to ask for extension... I want port 324 to the jspui
[16:30] <bollini> PeterDietz ++
[16:31] <mhwood> Do we accept 324? then adding JSPUI support could be further work identified for the issue.
[16:31] <bollini> no it is better to do the work togheter
[16:32] <bollini> it should be really easy, we can share the utility class between the two UI
[16:32] <hpottinger> 324 +1, extension granted, PeterDietz++
[16:32] <hpottinger> unfortunately, beer is analog
[16:32] <mhwood> 324 +1, we need JSPUI extension.
[16:33] <bollini> I will try to fix the 324 over the weekend
[16:33] <mhwood> Do you have enough to do? :-)
[16:33] <bollini> so as it is really easy I hope that you can trust me and give pre-approved for both 324 XML and the JSPUI porting
[16:34] <hpottinger> trust already granted, but affirmed
[16:34] <mhwood> Yes.
[16:34] <bollini> ok
[16:34] <bollini> 324: YES | pre-approved with jspui porting
[16:35] <mhwood> I think we finished the list! (Other than bugfixes, which we deferred)
[16:35] <bollini> thanks to all! I leave now
[16:35] <mhwood> Thanks again!
[16:35] <hpottinger> along those lines, I don't think we discussed 196 earlier this week, OK with you all if I merge it after confirming?
[16:35] <tdonohue> wow! Thanks all! We can just follow up on any deferred/needing final OK next week.
[16:35] <bollini> 196 yes
[16:36] <bollini> bye
[16:36] <kompewter> bye
[16:36] <mhwood> 196 yes
[16:36] <hpottinger> yay!
[16:36] * bollini (~chatzilla@193.206.99.195) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258])
[16:36] <hpottinger> now I just have to parse this transcript
[16:37] <hpottinger> kompewter, I should just be able to whisper a regex to you and you should do the parsing for me
[16:37] <hpottinger> get to work on that, will ya?
[16:39] <hpottinger> man, did we really just meet for 4 hours?
[16:39] <tdonohue> 3.5 :)
[16:40] <tdonohue> good job though, RT! Things are looking good, just took a bit of Fri morning effort :)
[16:40] <hpottinger> nap time!
[16:41] <PeterDietz> ohh geez. Sadly. I think I have some slight input on DS-1475 / PR#324.. The Controller (JAVA) shouldn't also be the view...
[16:41] <kompewter> [ https://jira.duraspace.org/browse/DS-1475 ] - [#DS-1475] Improvement of Collection Dropdown - DuraSpace JIRA
[16:41] <PeterDietz> <xsl:choose>
[16:41] <PeterDietz> <xsl:when test="string-length(@title) > 50">
[16:41] <PeterDietz> <xsl:variable name="title_length" select="string-length(@title)"/>
[16:41] <PeterDietz> <xsl:value-of select="substring(@title,1,15)"/>
[16:41] <PeterDietz> <xsl:text> ... </xsl:text>
[16:41] <PeterDietz> <xsl:value-of select="substring(@title,$title_length - 25,$title_length)"/>
[16:42] <PeterDietz> </xsl:when>
[16:42] <PeterDietz> <xsl:when test="@title">
[16:42] <PeterDietz> <xsl:value-of select="@title"/>
[16:42] <PeterDietz> </xsl:when>
[16:42] <PeterDietz> <xsl:otherwise>
[16:42] <PeterDietz> <xsl:value-of select="@href"/>
[16:42] <PeterDietz> </xsl:otherwise>
[16:42] <PeterDietz> </xsl:choose>
[16:42] <PeterDietz> Here is where you could inject XSL to truncate the length of a string, and add ellipsis.. As oppsed to making Java limit the output data.
[16:42] <mhwood> Please note the PR. There is time for fixing.
[16:45] <mhwood> I agree, CollectionDropdown should just supply data and let the theme do the rendering.
[16:45] <hpottinger> 324: YES | requires rework as suggested by PeterDietz
[16:48] <PeterDietz> Plus, if using Java to do this. It might be better to use StringUtils.abbreviate(title, 50); http://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringUtils.html#abbreviate(java.lang.String, int)
[16:48] <kompewter> [ StringUtils (Commons Lang 2.6 API) ] - http://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringUtils.html#abbreviate(java.lang.String,
[16:54] <mhwood> Notes on the PR or the issue would be good.
[16:54] <hpottinger> I'm having fun with SublimeText2's find and multi-line copy/paste
[16:55] <mhwood> Never mind, I see it's being done. Thanks!
[16:56] <hpottinger> https://gist.github.com/hardyoyo/898e9275d8e7a7aacca8
[16:56] <kompewter> [ dspace 4.0 PR review results ] - https://gist.github.com/hardyoyo/898e9275d8e7a7aacca8
[16:56] <mhwood> Very nice! Thanks!
[16:58] <hpottinger> thanks are really due to bollini's consistency
[16:58] <mhwood> Thanks to both.
[17:00] <hpottinger> unfortunately, that's just from today's meeting
[17:00] <hpottinger> parsing Wednesday's transcript will be a bit more of a challenge
[17:02] <mhwood> I'm wondering how this interacts with the JIRA tickets, which are scooped up and formatted into tables on the wiki page.
[17:06] <hpottinger> alas, I think I'm going to have to cull Wednesday's transcript by hand
[17:20] * terryb (~chatzilla@141.161.13.66) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 17.0.9/20130911042038])
[17:22] <hpottinger> oi, I'm glad we made today's meeting parse-able
[17:25] <tdonohue> well, sorry for the lack of parseability on weds. I wasn't much thinking about that.
[17:45] <hpottinger> no prob, I see I'm late for a meatspace meeting, gotta run, later!
[17:45] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Quit: Later, taterz!)
[19:26] * misilot (~misilot@p-body.lib.fit.edu) Quit (Quit: Leaving)
[20:29] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:15] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Remote host closed the connection)
[21:15] * PeterDietz (~peterdiet@dhcp-164-107-232-191.osuwireless.ohio-state.edu) has joined #duraspace
[21:19] * PeterDietz (~peterdiet@dhcp-164-107-232-191.osuwireless.ohio-state.edu) Quit (Ping timeout: 246 seconds)
[21:25] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[21:34] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[22:13] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.