Timestamps are in GMT/BST.
[6:29] -brooks.freenode.net- *** Looking up your hostname...
[6:29] -brooks.freenode.net- *** Checking Ident
[6:29] -brooks.freenode.net- *** Found your hostname
[6:30] -brooks.freenode.net- *** No Ident response
[6:30] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:30] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:30] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:46] * helix84_ (~ctenar@195.178.95.132) Quit (Remote host closed the connection)
[12:26] * fasseg (~fas@HSI-KBW-095-208-235-163.hsi5.kabel-badenwuerttemberg.de) has joined #duraspace
[13:18] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:34] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[17:50] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:21] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[19:57] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:00] <tdonohue> Hi All, it's time for our weekly DSpace Developers Mtg. Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-11-13
[20:01] <kompewter> [ DevMtg 2013-11-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-11-13
[20:01] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) has joined #duraspace
[20:01] <tdonohue> today is obviously all about 4.0 & Testathon and next steps
[20:02] <tdonohue> Not sure of the best place to start here, but we still have several semi-high priority tickets (linked off agenda) to figure out resolutions/volunteers for. I'm sure there are also tickets I've missed adding to the agenda
[20:03] <hpottinger> I'm puttering away at getting things running on Oracle
[20:03] <tdonohue> In my mind though, some of the highest priority tickets though are those related to the "Discovery by default" change in 4.0. Namely DS-1749 and DS-1621.
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1749 ] - [DS-1749] Graceful deprecation for different index update launcher commands - DuraSpace JIRA
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1621 ] - [DS-1621] Search in Item mapper don't work without lucene search provider - DuraSpace JIRA
[20:04] <helix84> https://wiki.duraspace.org/display/DSPACE/DSpace+4.0+indexing+commands
[20:04] <kompewter> [ DSpace 4.0 indexing commands - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+4.0+indexing+commands
[20:04] <helix84> I tried to make a summary here
[20:04] <tdonohue> thanks helix84!
[20:04] <tdonohue> so, helix84's link is related to 1749.. We can start there
[20:05] <helix84> Sorry it isn't as detailed as I planned it to be, but I hope I have covered all the options we discussed last time.
[20:05] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:06] <hpottinger> thanks, helix84, this helps quite a bit
[20:06] <tdonohue> yes, I think it does help give a better lay of the land (especially the options in "Problem A" -- the "index" commands)
[20:06] <hpottinger> if we go with option 1, I'd like to see the suggested documentation
[20:09] <tdonohue> Honestly, with the "index" commands, I'm starting to lean towards *Option 2* (doing away with commands like "index" "index-init" "index-update" and moving everything to more explicit commands). That way it's much clearer what you must use.
[20:10] <tdonohue> I know it makes the upgrade annoying in some ways...but at least it makes things much clearer
[20:10] <hpottinger> just so I'm clear (I'm still not a discovery user), with default of discovery on, we just plain don't need to run index-init/index-update, we only ever need to run update-discovery-index?
[20:10] <tdonohue> correct, hpottinger
[20:10] <helix84> tdonohue: well, explicit is better than what we have (index, index-init/index-update sound generic, but aren't) and while it would be better to be smart about the currently set backend, it's not an easy problem
[20:10] <helix84> hpottinger: true
[20:12] <helix84> hpottinger: IIRC, you still needed it in 3.0 to fill the browse indices, unless you configured the new (non-default in 3.0) Solr-backed browse class
[20:12] <tdonohue> helix84: yes, I agree it'd be better to be "smart". But, as you laid out well (on that wiki page), that may not be a very easy problem to tackle in the near term. So, if we cannot be "smart" and auto-determine your backend, it seems (to me) that the next best option is to be more explicit about what index tool works with what backend (your Option 2)
[20:13] * kstamatis (2ebe410b@gateway/web/freenode/ip.46.190.65.11) has joined #duraspace
[20:14] <mhwood> Why can we not? event.dispatcher.default.consumers lists the consumers which will be called. If browse is listed, browse should be initialized/updated; if discovery is listed, discovery should be initialized/updated.
[20:14] <hpottinger> OK, so, demo.dspace.org has a cron job that resets the content every so often, it currently runs index-init, but it also runs update-discovery-index, we need to comment out the index-init
[20:15] <tdonohue> hpottinger: yes. For 3.x that 'index-init' was needed (as helix84 explained), but now it is not.
[20:16] <helix84> mhwood: I haven't finished hunting down all the related config options, but note there is e.g. browseDAO.class and browseCreateDAO.class, what if a user changes each to work with a different backend (I know, it sounds stupid, but we're currently making it possible)
[20:16] <tdonohue> mhwood: I think the question in my mind is whether it's really that easy. We need someone to try it. If it's possible quickly, then maybe we can. Otherwise, maybe we need to look at something simple for 4.0, and enhancing for 5.0
[20:17] <mhwood> If a site is using both backends, they should both be called.
[20:17] <mhwood> OK, if being smart is not so simple then yes, do something simple now and rework it later.
[20:18] <hpottinger> actually, I see a note in the demo.dspace.org that we need to disable the reset script during testathon, doing so now
[20:19] <tdonohue> Yep. So my preference is (1) "smartly determine your backend" and index in the right area(s)....but, if that's too hard to do quickly, then (2) just remove the old "index" scripts and have "index-lucene" and "update-discovery-index" (or some other similarly named scripts which explicitly tell you which backend they work with)
[20:20] <helix84> tdonohue: that would be my preference, too. Just one note - please, let's be consistent for once and call it update-lucene-index.
[20:20] <tdonohue> helix84: fine by me :)
[20:20] <mhwood> Yes.
[20:21] <tdonohue> or, we rename them both to "index-lucene" and "index-discovery". But, I agree consistency is best
[20:21] <helix84> that brings me to one thing that is not clear to me
[20:21] <hpottinger> FYI, reset-dspace-content script modified to no longer call index-init, and crontab commented out for testathon purposes
[20:21] <helix84> update-discovery-index is able to create, destroy and update
[20:22] <helix84> index-update/index-init each have one task
[20:22] <helix84> and I'm not familiar with "index"
[20:22] <mhwood> index-foo are aliases for "index --foo"
[20:22] <mhwood> Right?
[20:23] <mhwood> index-init = index -f -r
[20:23] <helix84> mhwood: I just listed options of "index" and I don't see init and update
[20:23] <tdonohue> no, mhwood
[20:23] <mhwood> index-update = index -i
[20:23] * kstamatis_ (2ebe410b@gateway/web/freenode/ip.46.190.65.11) has joined #duraspace
[20:24] <mhwood> Well, for some value of "alias". Sorry, should have checked the config. and then spoken instead of the other way around.
[20:24] * kstamatis (2ebe410b@gateway/web/freenode/ip.46.190.65.11) Quit (Ping timeout: 250 seconds)
[20:24] <tdonohue> look at the launcher folks. "index" is only the Browse indexes. "index-init" is Browse + ItemCounter + Lucene. "index-update" is Browse + ItemCounter + Lucene
[20:24] <tdonohue> https://github.com/DSpace/DSpace/blob/master/dspace/config/launcher.xml#L122
[20:24] <kompewter> [ DSpace/dspace/config/launcher.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/launcher.xml#L122
[20:24] <helix84> plus, see the table on my wiki page - index-init/index-update call more than once class for some reason.
[20:24] <helix84> tdonohue: I see, thanks.
[20:24] <mhwood> Ah.
[20:25] <tdonohue> Why they were named that way, I have *no idea*. They should all be one script in my opinion, but they were not built that way
[20:26] <helix84> Note that in 4.0 with Solr, there's no need to call itemcounter separately. But it would be needed with Lucene.
[20:26] <tdonohue> IIRC, "index-init" and "index-update" existed first. Then someone created "index" (generic) later on and named it oddly as it only deals with the Browse index
[20:29] <helix84> This only seems to get messier. Where does it leave us?
[20:30] <tdonohue> So, it sounds like we are in agreement that "smart" indexing is best (if possible). But, if not possible, then we should rename our index scripts to explicitly say "lucene" and "discovery"? Does anyone disagree with that? Just want to make sure we are on the same initial page.
[20:30] <helix84> ,1
[20:30] <helix84> +1
[20:30] <mhwood> +1
[20:30] <mhwood> It looks like we should rename "index" too.
[20:30] <helix84> mhwood: rename to what?
[20:30] <mhwood> lucene-index?
[20:30] <tdonohue> +1. The "index" script would need renaming too. (perhaps to "index-browse" or something)
[20:31] <helix84> just to make sure, index is *only* the DB-backed browse index, right?
[20:32] <hpottinger> ideally it would be nice if developers on autopilot don't get bitten by the fact that the script names changed
[20:32] <tdonohue> correct, as far as I know, 'index' is *only* the Browse DB index, helix84
[20:32] <mhwood> I see that build.xml calls IndexBrowse and DSIndexer.
[20:33] <helix84> then let's make it explicit from the name, and have something like update-db-index or db-browse-index or something.
[20:34] <tdonohue> hpottinger: In some ways, I'd rather they get "bitten" than assume they will properly read the upgrade docs. So, if we rename these scripts, we could still leave "dummy" scripts that print "Do not use 'dspace index-init'. It has been replaced by 'dspace update-lucene-index'. Modify your scripts/cron jobs appropriately." ;)
[20:34] <tdonohue> helix84: yep, I agree. "index" would need to be renamed to something more explicit as well
[20:35] <helix84> tdonohue: I agree with the first part. But I prefer a missing script (which would be loud and clear) to and existing script which runs from cron with an error that noone reads.
[20:36] <tdonohue> helix84: true
[20:36] <tdonohue> helix84: that is a good point. agreed
[20:37] <hpottinger> missing script, one would hope, would get noticed... as long as they aren't doing the old >/dev/null trick in crontab
[20:37] <mhwood> If nobody is reading the cron logs, what does it matter how the command refused to do what one thought it would do?
[20:38] <hpottinger> I vote we make the replacement script really annoying and have it e-mail the configured admin
[20:38] <tdonohue> Ok, so I think the question here is now: Would anyone(s) have some time to briefly investigate whether it is possible to create a "smart" script? Or are we just going straight to renaming these scripts?
[20:38] <hpottinger> rename now, smarts later
[20:39] <helix84> hpottinger++
[20:39] <helix84> I agreed with Hardy's emailing suggestion
[20:40] <helix84> with the later one, too, actually :)
[20:41] <tdonohue> Ok, so "rename now, smarts later". In the essence of "rename now", should we just do a *full overhaul*? I.e. rename *everything* to "index-[backend]" or "[backend]-index".... this would include renaming "update-discovery-index". Or do we use "update-[backend]-index" as the new script naming scheme?
[20:41] <mhwood> Yeah, email sounds good. Time is short, so maybe best to just punt the smart version down the line.
[20:43] <tdonohue> (I admit to never much liking the "update-discovery-index" name...as it does more than "update"...but, I'm fine if folks want to keep that)
[20:43] <helix84> tdonohue: I never really liked that it says *update*-discovery-index but it's actually able to destroy and create it, too, so I'd take this opportunity to change all to index-backend
[20:43] <tdonohue> helix84 and I just said the same thing :)
[20:44] <mhwood> May I say it too?
[20:44] <tdonohue> sure
[20:44] <mhwood> Consider it said.
[20:44] <helix84> that's all folks :D
[20:44] <hpottinger> +1 y'all
[20:45] <tdonohue> Ok, so it sounds like we've settled on renaming *ALL* indexing related scripts to "index-[backend]"?
[20:45] <mhwood> Yes.
[20:45] <helix84> yes, but we still have to discuss some details
[20:45] <hpottinger> if I understand correctly, that involves changing the plumbing of the index command a bit
[20:46] <helix84> namely, as we just noted, index-init/index-update did 2 functions together (I just updated the table on the wiki to make it clearer)
[20:46] <helix84> do we split these functions into separate commands as they (can) use separate backends?
[20:47] <helix84> Lucene doesn't have browse, but Solr has all of browse, search and itemcounter
[20:47] <mhwood> I think we have to, if the names are not to be confusing all over again.
[20:47] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:48] <helix84> so we would have index-discovery, index-lucene, index-db-browse and itemcounter
[20:48] <helix84> the forst one does 3 things, the other 3 do all 1 thing
[20:48] <helix84> s/all/each/
[20:48] <kompewter> helix84 meant to say: the forst one does 3 things, the other 3 do each 1 thing
[20:49] <tdonohue> Makes sense, helix84. My only question would be if we want to offer a direct replacement for "index-init" that is "index-lucene-init" (and just calls index-lucene, index-db-browse and itemcounter)
[20:50] <tdonohue> (otherwise, if I understand correctly, there is no direct replacement for "index-init" or "index-update"...instead you must call all three?)
[20:51] <helix84> tdonohue: I don't have an opinion yet, but note that it would require you to change at least 3 configuration options to use it - the search, browse and itemcounter class
[20:51] <mhwood> Make separate for clarity. They may all go away in a year. (TBD)
[20:52] <hpottinger> the docs for this will be... interesting...
[20:53] <helix84> hpottinger: we'll just say we're doing away with magic
[20:53] <tdonohue> that's my worry.
[20:53] <mhwood> Apparently they *should* be...interesting...now.
[20:53] <helix84> it's actually the state we had that was hard to understand, not what we're moving to now
[20:54] * kstamatis_ (2ebe410b@gateway/web/freenode/ip.46.190.65.11) Quit (Ping timeout: 250 seconds)
[20:54] <hpottinger> right, the interesting part will be first explaining what it used to be (and possibly why) and then what it is now. Or, maybe we just explain *now* and skip the rest?
[20:54] <helix84> hpottinger: I'm not sure I understood the last sentence.
[20:55] <hpottinger> it'll be hard to explain why what we're changing to is better, without first explaining what it is we used to have
[20:55] <helix84> as I understood it, you mean Option 1 or very similar
[20:56] * kstamatis (2ebe410b@gateway/web/freenode/ip.46.190.65.11) has joined #duraspace
[20:56] <helix84> ok. yes, we'll definitely have to explain both. but now that we cleared it up for ourselves it's not so hard to write it down.
[20:56] <mhwood> Yay!
[20:57] <hpottinger> +1 exhuberance
[20:57] <tdonohue> I'm hesitant to remove the ease of use of "index-init" and "index-update", when it's so easy to just add in essentially an "alias" to launcher.xml. This is what I'm thinking: https://gist.github.com/tdonohue/7456271
[20:57] <kompewter> [ New Index commands? ] - https://gist.github.com/tdonohue/7456271
[20:58] <helix84> tdonohue: see my note about at least 3 configuration options above
[20:58] <mhwood> Indeed, we're already making it hard to use the old indexing by changing the default.
[20:59] <mhwood> We still need to have that discussion about what happens to the old indexing. (Agenda item 2)
[20:59] <tdonohue> hmmmm... But, what about the folks who already have those *3 configuration options* in their local DSpace (i.e. they are running 3.x with Lucene)?
[21:01] <tdonohue> I agree with you that it's now harder to use Lucene in 4.0. I just don't understand why someone would want to enable Lucene *without* Browse DB? So, why separate them out?
[21:01] <mhwood> Dunno. I can't recall when I last ran any of these on a production system.
[21:01] <helix84> tdonohue: I'm not sure I get your point. What about them? 4.0 has a different configuration. And you shouldn't re-use old configuration files, that's one of the things I most often recommend against.
[21:02] <tdonohue> It seems like the instructions to *reenable* Lucene would involve tweaking *all three* of those config options (search/browse/itemcounter) and then running "index-lucene-init" (or all three scripts separately)
[21:02] <helix84> tdonohue: true
[21:02] <tdonohue> I guess I question not replacing "index-init/index-update" if there's no way to really run Lucene without the DB browse tables anyway
[21:03] <tdonohue> hence, as I suggested in my gist: https://gist.github.com/tdonohue/7456271
[21:03] <kompewter> [ New Index commands? ] - https://gist.github.com/tdonohue/7456271
[21:03] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) Quit (Quit: Page closed)
[21:03] <helix84> tdonohue: Since old lucene (not a potential discovery-lucene) is in legacy mode, we might as well not make it harder to use and have "index-lucene-init" that does all 3. It's an option.
[21:05] <tdonohue> yep, exactly helix84. I'm just suggesting that for 4.x we have an "index-lucene-init" and "index-lucene-update" as direct replacements of their 3.x equivalents. Then in 5.0 we can determine if all the 'index-lucene*' commands get dropped or not.
[21:06] <tdonohue> that way we still support Lucene in the same way, but we are essentially "deprecating" it
[21:06] <helix84> Keep in mind that if you forget to configure the solr itemcounter DAO class back to db-browse, it will complain about the Solr itemcounter DAO not having caching.
[21:07] <tdonohue> yes, we need to note all those instructions in the docs. Do we even have all the instructions on how to "enable Lucene" in our 4.x docs yet?
[21:07] <helix84> So it may seem easy to have a new command with the old semantics, but it may fail in unexpected ways if you don't follow the docs closely.
[21:07] <mhwood> If we have no time to make the code smart, then the administrators will have to be smart.
[21:07] * hpottinger is excited about all this new documentation someone is going to write!
[21:07] <helix84> tdonohue: we do, I linked to it at the beginning of this meeting
[21:08] <tdonohue> right right. which is why we need the docs. I agree, none of this is perfect. I just hesitate towards removing useful Lucene scripts since we are supporting Lucene still
[21:08] <mhwood> Sure, rename them. We are going to revisit all this later, right?
[21:09] <tdonohue> yes. we'll revisit for 5.0
[21:09] <helix84> so, we're removing index-init/index-update because we want people to *notice* there are big changes underneath. If we essentially just rename them, they will try to use the new ones in the old ways, but they can easily run into problems.
[21:11] <tdonohue> So, are we in agreement here? Not sure if we are or not. This is what I propose: https://gist.github.com/tdonohue/7456271 (It's essentially a simple rename of scripts in launcher.xml...with the addition of one new one)
[21:11] <kompewter> [ New Index commands ] - https://gist.github.com/tdonohue/7456271
[21:12] <helix84> apart from what I just said, I'm not sure what you're suggesting index-lucene should do when we have index-lucene-init/index-lucene-update
[21:12] <tdonohue> well, we could drop 'index-lucene'...that's true
[21:13] <tdonohue> which makes it all just a simple renaming of scripts in "launcher.xml"... no new additions
[21:14] <helix84> OK, let's backtrack here. What does renaming win us?
[21:14] <mhwood> current "index" does a lot more than index-init or index-update. Take a look at the options.
[21:14] <tdonohue> current "index" becomes "index-db-browse"...here...let me clean up my Gist
[21:15] <tdonohue> https://gist.github.com/tdonohue/7456271
[21:15] <kompewter> [ New Index commands ] - https://gist.github.com/tdonohue/7456271
[21:15] <tdonohue> helix84: renaming wins us *clarity* which is what we've been talking about this whole time...clarifying what "index" and "index-init" and "index-update" actually do
[21:17] <helix84> right
[21:18] <tdonohue> I'm not sure I understand here what folks opinions are. Can we all clarify where we stand? Anyone else listening in want to express their opinions? I feel like we are talking in circles the last few weeks around this issue. There seems to be two overlying options: (1) Lots of 4.x documentation to explain why you shouldn't use "index/index-init/index-update" by default, OR (2) rename scripts for clarity.
[21:18] <helix84> IF we do what you suggest in your gist, I think we shouldn't add index-lucene because a) its meaning is not immediately obvious in presence of index-lucene-init and -update and b) we didn't have it before, so we don't need to add a new feature for legacy backend
[21:18] <mhwood> I think that "clear" means different things, depending on how much you know about what DSpace is doing with indexing.
[21:19] <tdonohue> helix84: I agree with that statement
[21:20] <hpottinger> hmm.... my trusty rusty old Oracle-based dev stack just mysteriously died
[21:21] <helix84> tdonohue: I think what you proposed is in line with what we agreed on today and I don't immediately see any new problems with it.
[21:21] <tdonohue> feel like we are really a bit "stuck" on this issue, and I am not sure how to move us forward. Are we in agreement here on renaming? Are others now disagreeing based on the proposed renaming?
[21:22] <mhwood> At this point I'm more interested in a consensus than in what (among the current options) it is.
[21:23] <tdonohue> well, it sounds like at least two of us (helix84 and I) agree on this (I removed 'index-lucene' for reasons helix84 mentioned): https://gist.github.com/tdonohue/7456271
[21:23] <kompewter> [ New Index commands ] - https://gist.github.com/tdonohue/7456271
[21:24] <helix84> I just want to note for anyone who only reads this log later that Tim changed this gist during the meeting several times, so you may want to check the Revisions link to see the old versions we were discussing.
[21:24] <tdonohue> I can add this to the initial ticket that Bram created and we can work on a PR (which should be a simple rename in launcher.xml) and also work on Doc changes
[21:25] <tdonohue> good point, helix84: yes the history of that gist show all the versions I went through
[21:25] <helix84> OK, this addresses Problem A. We agreed not to address Problem C in 4.0 (if at all). What about B) - it seems we'll be relying only on documentation to clarify this.
[21:26] <mhwood> Given the timing I think we may have to accept that.
[21:27] <tdonohue> Problem B should be in the documentation on how to switch to "re-enabling" Lucene? with the renaming of the scripts, it'd only be an error if you didn't properly enable all aspects of Lucene (namely itemcounter) and your ran 'index-lucene-init'
[21:28] <tdonohue> So the error would be a "you didn't follow the documentation for enabling Lucene properly" error
[21:28] <helix84> tdonohue: true, just note that's exactly what the testathon ticket was about.
[21:29] <tdonohue> Yep. It was only an error in testathon cause we haven't the docs or renaming in place to point to the solution.
[21:29] <tdonohue> So we should be able to "resolve" that ticket once we have renamed the scripts & enhanced the docs as appropriate
[21:30] <tdonohue> Ok, I know we are now 1.5 hrs into a 1 hour meeting
[21:30] <tdonohue> But, I think we need to highlight DS-1621. It needs eyes
[21:30] <kompewter> [ https://jira.duraspace.org/browse/DS-1621 ] - [DS-1621] Search in Item mapper don't work without lucene search provider - DuraSpace JIRA
[21:30] <mhwood> "why index-init/index-update need to use ItemCountDAO" is because that's part of what they are intended to do.
[21:31] <tdonohue> 1621 is a major issue with "Discovery by default". We have broken the Item mapper and it needs fixing
[21:32] <helix84> Hmm, steps to reproduce? I don't know where to go look.
[21:32] <tdonohue> So, if someone out there listening wants to look into it, it'd be great. I don't know that we can release 4.0 without a fix.
[21:33] <tdonohue> helix84: (1) Create twoCollections, (2) Create an Item (in one collection), (3) in the other collection, open the "Item Mapper" and attempt to map the Item
[21:34] <tdonohue> (this is XMLUI only though)
[21:34] <tdonohue> oh wait? is this fixed?
[21:34] <tdonohue> it's not erroring on demo.dspace.org
[21:36] <helix84> ok, here's the relevant class that needs to be changed: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/administrative/mapper/SearchItemForm.java
[21:36] <kompewter> [ DSpace/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/administrative/mapper/SearchItemForm.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/administrative/mapper/SearchItemForm.java
[21:37] <helix84> tdonohue: I think on demo we still have the lucene index filled in
[21:37] <tdonohue> yep, you are correct. There is still a lucene index on demo
[21:37] <tdonohue> so, that's why it is "working" there.
[21:39] <tdonohue> So, 1621 needs eyes/investigation/help. If anyone out there wants to chip in, we'd appreciate it
[21:39] <helix84> I just added steps to reproduce and links to the class to Jira comments.
[21:40] <tdonohue> thanks helix84. that helps
[21:40] <helix84> tdonohue: off-topic: I can't edit my own Jira comment (You do not have the permission for this comment.)
[21:41] <tdonohue> So, on to a more general topic. As we are nearing the end of 4.0 Testathon, it's about time to start taking "stock" of where we are at with 4.0. This means we need to begin reviewing all the tickets marked "fix for 4.0" in JIRA and also any fresh ones that have come in during Testathon
[21:42] <tdonohue> Currently we have 68 "fix for 4.0" tickets in JIRA. I suspect some are nearly fixed (may just need docs), some may need eyes, and others may need to just be rescheduled. But, we need to figure out which are which
[21:42] <tdonohue> https://jira.duraspace.org/browse/DS-1776?jql=project%20%3D%20DS%20AND%20fixVersion%20%3D%20%224.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
[21:42] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1776?jql=project%20%3D%20DS%20AND%20fixVersion%20%3D%20%224.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
[21:42] <kompewter> [ https://jira.duraspace.org/browse/DS-1776 ] - [DS-1776] Unable to read statistics core after upgrade to DSpace 4.0 - DuraSpace JIRA
[21:42] <helix84> new Jira :)
[21:44] <helix84> DS-1374 would be a new feature, I'd reschedule it for 5.0
[21:44] <kompewter> [ https://jira.duraspace.org/browse/DS-1374 ] - [DS-1374] AIP Backup & Restore functionality does NOT backup/restore past versions of Items - DuraSpace JIRA
[21:44] <tdonohue> I don't really want to bring up any more topics for today, as we are way "over time". But, I do want to highlight that we need to be reviewing JIRA tickets and making some decisions here.. I think we still have a bit of work ahead before 4.0 is ready, but I am not sure exactly how much is left (& some of it may be documentation)
[21:45] <tdonohue> This to me seems like an RT role..to try and help us determine where are "gaps" our with 4.0 right now, and what still needs eyes/help.
[21:45] <mhwood> I agree.
[21:45] <tdonohue> Everyone though is encouraged to review tickets and either close them, work on them or reschedule them if they are not "doable" for 4.0
[21:46] <tdonohue> thanks, mhwood
[21:47] <tdonohue> I'll still be hanging around here for a bit, to chat as needed. But, I'm not going to call any other meeting topics. If folks have anything they want to discuss though, please feel free.
[21:48] * kstamatis (2ebe410b@gateway/web/freenode/ip.46.190.65.11) Quit (Quit: Page closed)
[21:48] <mhwood> Any thoughts on agenda item 2? What do we do with old indexing *after* 4.0 releases?
[21:49] <helix84> mhwood: that's a large topic that we'd better revisit when there are more folks here and during a proper DevMtg time
[21:50] <tdonohue> mhwood: My opinion is actually we should consider *deprecating* the Lucene Java code in 4.0. Then, after 4.0 we can decide whether we want to replace it with new code (hooked into Discovery), or if we remove it. Either way though, it seems like the old code should likely go away
[21:50] <helix84> mhwood,,
[21:50] <tdonohue> but, I agree, we need to revisit with a larger group, or discuss on JIRA
[21:50] <helix84> mhwood++
[21:51] <helix84> I vaguely remember we already agreed on Lucene deprecation, with removing TBD
[21:51] <tdonohue> we likely should create a JIRA ticket for that...and determine which classes exactly need deprecation warnings added
[21:52] <tdonohue> (plus a JIRA ticket would be a good place to start the discussion and ensure no one else has huge objections)
[21:52] <helix84> I'll have to excuse myself now. Good night.
[21:52] <mhwood> Good night.
[21:53] <mhwood> I would write one but I'm not yet sure what it would say.
[21:53] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:54] <tdonohue> "Deprecate Lucene Java classes" :) I can create one here in a sec. I won't have a chance to find all the Java classes, but I can at least describe the issue at hand
[21:56] <helix84> mhwood: I just remembered, I have a branch with a large bunch of typo fixes that I waited with in order not to introduce conflicts. Is it a good time now to fire a PR?
[21:56] <mhwood> Might be good to get them in before the bug fixes start rolling in (we hope).
[21:57] <helix84> Good. I'll try to find it tomorrow.
[22:00] <mhwood> Must go. Thanks, all!
[22:00] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:03] <helix84> I figureed I'll just get it done, so here it is: https://github.com/DSpace/DSpace/pull/390
[22:03] <kompewter> [ fix a bunch of typos by helix84 · Pull Request #390 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/390
[22:03] <helix84> click away :)
[22:06] <helix84> one more easy job: https://github.com/DSpace/DSpace/pull/391
[22:06] <kompewter> [ JavaDoc for statistics converter/importers by helix84 · Pull Request #391 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/391
[22:07] <helix84> Am I just not looking correctly or is Travis gone from our GitHub?
[22:08] <tdonohue> it's there..I see it... It says "waiting to hear about.."
[22:09] <tdonohue> (though you may need to be logged in to GitHub to see that message, as I know some of the Travis stuff only appears to GitHub project admins)
[22:10] <helix84> I see it now, I didn't see it before. Logged in all the time. *shrug*
[22:10] <helix84> I just realized one "problem" with our renaming decision
[22:10] * helix84 ducks
[22:11] <helix84> index-lucene-* do not just deal with lucene, but also DB (actually they work with whatever the configured browse and itemcounter class is), so the name is not an improvement
[22:12] <tdonohue> it's still better. As I said, I'm not sure you really can use Lucene without the DB (or visa versa)...they are "intertwined" as it is...so it's impossible for full clarity there
[22:13] <tdonohue> the main message is that "index-lucene-*" only works if you have taken steps to enable Lucene (and the DB browse).
[22:15] <tdonohue> created a new JIRA ticket for this renaming of commands: DS-1788
[22:15] <kompewter> [ https://jira.duraspace.org/browse/DS-1788 ] - [DS-1788] Rename Indexing scripts for clarity - DuraSpace JIRA
[22:15] <tdonohue> Also created a JIRA ticket which suggests deprecating Lucene Java classes: DS-1789
[22:15] <kompewter> [ https://jira.duraspace.org/browse/DS-1789 ] - [DS-1789] Deprecate Lucene Java classes - DuraSpace JIRA
[22:23] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[23:15] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:19] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.