Timestamps are in GMT/BST.
[7:09] -kornbluth.freenode.net- *** Looking up your hostname...
[7:09] -kornbluth.freenode.net- *** Checking Ident
[7:09] -kornbluth.freenode.net- *** Found your hostname
[7:09] -kornbluth.freenode.net- *** No Ident response
[7:09] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[7:09] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[7:09] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:02] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[14:07] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:22] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:48] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) has joined #duraspace
[14:51] * tdonohue reminds everyone we have a DSpace Developers Mtg at the top of the hour (~10 mins): https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-12-16
[14:59] * KevinVdV (~KevinVdV@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:00] * pmarrone (~pmarrone@proxy3.psi.unc.edu.ar) has joined #duraspace
[15:00] <tdonohue> Hello all, welcome! It's time for our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-12-16
[15:00] <kompewter> [ DevMtg 2015-12-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-12-16
[15:02] <tdonohue> As usual, the primary topic for today is 6.0, with an eye on getting our features finalized. As noted in the agenda, we've missed our tentative Feature Freeze date (was supposed to be last week), so we need to set a new goal and work to try and finalize our features ASAP
[15:03] <tdonohue> While I realize we are hitting up against holidays now, I'd like to figure out a plan for getting all our outstanding features tested / approved. It feels like we have many that have "stalled" and need someone(s) to help test and move each forward
[15:03] <mhwood> I thought that "feature freeze" meant "no new features will be considered for 6.0". But we did miss the "feature complete" date as well, right?
[15:04] <mhwood> Today I want to try out enhanced configuration. I got it built yesterday but ran out of time to run int.
[15:04] <tdonohue> yes, mhwood, as of today we were supposed to have an RC1 (but we aren't close to that yet): https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-ReleaseTimeline
[15:04] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-ReleaseTimeline
[15:05] <tdonohue> I think we already have a limited set of "potential 6.0 features" to choose from. Those are the thirteen remaining 6.0 Feature PRs: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+milestone%3A6.0+label%3Afeature
[15:05] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+milestone%3A6.0+label%3Afeature
[15:05] <tdonohue> So, the next step is to actually make a decision on each, so that we can finalize our set of features and work towards stabilizing the codebase & releasing an RC1
[15:06] <mhwood> We also have a host of nonfeatures to consider. But it makes good sense to get through features first.
[15:06] <tdonohue> As we currently stand on "master", there's been a ton of awesome API-refactoring work, but be don't have any *user facing* features to show for it yet. :)
[15:07] <tdonohue> mhwood: yes, good point. There's tons of improvements hanging around as well (and bug fixes)
[15:07] <hpottinger> is the plan to merge commons config last?
[15:07] <mhwood> I would rather it go first.
[15:07] <KevinVdV> Do we want it go first ?
[15:07] <KevinVdV> It might delay other pull requests
[15:08] <mhwood> It's been sitting due to no testers.
[15:08] <tdonohue> DSPR#1104 (just pasting the PR in here)
[15:08] <kompewter> [ https://github.com/DSpace/DSpace/pull/1104 ] - DS-2654: Enhanced Configurations via Apache Commons Configuration by tdonohue
[15:08] <hpottinger> hey, there are quite a few of us here after all :-)
[15:08] <KevinVdV> I performed some testing & the only thing preventing me from a +1 right now is the maven filtering of the local.cfg file (which is only one line)
[15:08] <tdonohue> I will warn that it's *highly likely* it will break other PRs. I do want 1104 in ASAP (as it's been a pain to continually rebase)...but I don't want to do so to the detriment of other features that are ready
[15:09] <tdonohue> KevinVdV: Send me a PR on filtering that local.cfg. I don't have a good test scenario for what you want, but I'd be glad to add it in as needed
[15:10] <mhwood> Either it breaks other PRs, or other PRs break it multiple times. It's large and extensive. I'd rather break several smaller PRs than one big one over and over.
[15:10] <KevinVdV> Will create a pull request one of the following days
[15:10] <pbecker> I'm afaraid of what I would have to rebase.
[15:10] <hpottinger> rebasing is fun and easy :-)
[15:11] <mhwood> Actually I've been thinking that maybe local.cfg should not even participate in packaging. That way updates don't have to deal with a file that is purely local settings.
[15:11] <pbecker> Still today I have one last PR to rebase and one which had some recommendations from Kevin's review (btw: thank KevinVdV!).
[15:12] <pbecker> hpottinger: that depends. Rebasing after the service API was mostly bugfixing existing stuff and completely redoing the existing PRs. To be honest it was not so much fun.
[15:12] <tdonohue> mhwood: or perhaps we see if we can have local.cfg *optionally* participate in packaging. That was my initial intention... local.cfg isn't needed at the Maven level, but if you are storing it in your Source tree, it should be "discovered" and put in the right place.
[15:12] <pbecker> but of course: it proofed what a big step the service api is... ;-)
[15:14] <hpottinger> I see we have 13 feature PRs, I wonder if we have any improvement PRs?
[15:14] <mhwood> Oh, yes, we do.
[15:15] <hpottinger> oh, my, 27
[15:15] <tdonohue> hpottinger: yes, we do. But considering we haven't even made it through our feature lists, I hadn't brought them up yet
[15:15] <hpottinger> https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+milestone%3A6.0+label%3Aimprovement
[15:15] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+milestone%3A6.0+label%3Aimprovement
[15:15] * KevinVdV_ (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:15] * KevinVdV (~KevinVdV@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[15:15] * KevinVdV_ is now known as KevinVdV
[15:15] <mhwood> So, start at the bottom of features and work our way up?
[15:15] <tdonohue> Basically the message here is that we need help testing & approving these PRs. We're way behind, and not enough folks have stepped forward to test & +1 PRs of interest
[15:15] <hpottinger> well then, let's tackle the 13 first, then launch ourselves at the 27
[15:16] <tdonohue> agreed. If possible, I'd love to "assign" individual PRs to someone(s) to review & test. Some of these seem very close to ready, but just need a final run through
[15:16] <tdonohue> So, here's our list of 13...we'll start at the bottom: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+milestone%3A6.0+label%3Afeature
[15:16] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+milestone%3A6.0+label%3Afeature
[15:17] <tdonohue> DSPR#801 (currently assigned KevinVdV)
[15:17] <kompewter> [ https://github.com/DSpace/DSpace/pull/801 ] - DS-1262 CSV export of search results in XMLUI by wwelling
[15:17] <tdonohue> It looks like KevinVdV has been doing a code review here and has given useful feedback. Is this waiting on the PR creator?
[15:18] <KevinVdV> It is indeed waiting on the creator
[15:18] <tdonohue> Ok, I suggest skipping this for now then..it needs more work before we can talk merger
[15:18] <KevinVdV> Do we have a label to tag as “waiting for creator"
[15:18] <tdonohue> next up, DSPR#970 (also assigned KevinVdV)
[15:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/970 ] - DS-2625 Extendable control panel by kosarko
[15:19] <mhwood> He posted some notes yesterday.
[15:19] <tdonohue> KevinVdV: we don't have such a tag, but we could easily create one
[15:19] <KevinVdV> I will do a more in depth review & see if we can merge this. SPring isn’t mandatory
[15:20] <KevinVdV> So keep assigned to me
[15:20] <tdonohue> thanks, KevinVdV. I agree, Spring is likely not mandatory.
[15:20] <tdonohue> moving along, DSPR#988
[15:20] <hpottinger> Yep, can always refactor to Spring later
[15:20] <kompewter> [ https://github.com/DSpace/DSpace/pull/988 ] - [DS-2648] Full text available sidebar facet for Discovery by christian-scheible
[15:21] <mhwood> There is an issue for rethinking the way we do singleton plugins across the board, moving to Spring. We can fix that later.
[15:21] <tdonohue> (again KevinVdV is assigned on 988)
[15:21] <KevinVdV> & it has my +1 just a small question on default config
[15:21] <KevinVdV> So depending on what we agree this one can be merged
[15:21] <mhwood> helix84 also gave +1
[15:22] <hpottinger> this one looks ready, we just need a decision on enabling by default
[15:23] <hpottinger> and if we need another +1 on that, you can have mine, it's a nice bit of data and a nice feature
[15:23] <tdonohue> This feature seems useful to me. I'm OK with it being enabled by default, provided we have clear documentation on how to disable it.
[15:24] <KevinVdV> Anybody else object to me pressing the green button ? (Will keep the JIRA open for docs)
[15:24] <tdonohue> Speaking of which, this feature does need some basic documentation
[15:24] <mhwood> No objection here.
[15:24] <tdonohue> no objections. Seems good
[15:24] <hpottinger> helix84 is quiet here, but is commenting on PRs
[15:25] <hpottinger> no objections from me
[15:25] <KevinVdV> Merged
[15:25] <KevinVdV> I’ll follow on docs, onwards !
[15:25] <tdonohue> thanks!
[15:25] <tdonohue> ok, next up then... DSPR#989
[15:25] <kompewter> [ https://github.com/DSpace/DSpace/pull/989 ] - DS-2629 mediafilter addition: ExcelFilter.java by edgo914
[15:26] <tdonohue> This one seems like a useful & obvious feature...we should be indexing Excel docs too
[15:26] <tdonohue> I haven't tested it though, but I like the idea
[15:26] <KevinVdV> Will test, assign to me
[15:27] <tdonohue> thanks KevinVdV! I'll mention I've done a code review and the code looked fine to me. Just needs testing
[15:27] <KevinVdV> Will test in the coming days
[15:27] <hpottinger> I've just skimmed the code, it looks fine, just a matter of testing it
[15:27] <tdonohue> Ok, moving along then. Next up, DSPR#994
[15:27] <kompewter> [ https://github.com/DSpace/DSpace/pull/994 ] - DS-2659 new extensible platform health check reports with emailing by vidiecan
[15:28] <mhwood> Merge conflict
[15:28] <tdonohue> This one still has a merge conflict. Anyone want to "adopt it" or argue for it? Or do we just reschedule it?
[15:29] <tdonohue> It sounds *interesting* to me...but there's little docs, and the code itself needs help. So, unless someone wants to steward this, I think we have to reschedule it
[15:30] <tdonohue> (pinging helix84, since you commented on this previously...any interest in stewarding this?)
[15:30] <helix84> oh hi
[15:31] <helix84> I'll take look, let's leave it for now so we can come back to it next week
[15:31] <tdonohue> helix84: ok, I'm assigning it to you then, as a reminder :)
[15:31] <tdonohue> done. Next up, DSPR#1086
[15:31] <kompewter> [ https://github.com/DSpace/DSpace/pull/1086 ] - DS-2583: Quality Control Reporting via REST API (v4) by terrywbrady
[15:32] <KevinVdV> Took a look at the code & that is good for me now, but haven’t tested yet
[15:32] <tdonohue> terry-b's PR. He mentioned he won't make it to today's meeting, but I know he's been wanting to see this move forward
[15:32] <mhwood> Are all current issues addressed?
[15:33] <tdonohue> It seems like they've been addressed, or at least claimed to have been addressed
[15:34] <KevinVdV> But I notie that html pages have been attached since I last reviewe
[15:34] <KevinVdV> So a UI has been added
[15:34] <KevinVdV> to a rest.....
[15:35] <KevinVdV> So I wonder what the purpose of these files is
[15:35] <tdonohue> Yes, peterdietz pulled over those reports as "samples" to start from. See this comment: https://github.com/DSpace/DSpace/pull/1086#issuecomment-155943723
[15:35] <kompewter> [ DS-2583: Quality Control Reporting via REST API (v4) by terrywbrady · Pull Request #1086 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1086#issuecomment-155943723
[15:36] <hpottinger> thos are sample reports, yes?
[15:37] <tdonohue> yes, they are samples.
[15:37] <tdonohue> Tell you what, I'll take a closer look at this one. I've been meaning to anyhow, so I'll claim this and report back. It seems like it's mostly ready...just a matter of whether we include those samples or not, and ensuring the docs get moved over, etc
[15:38] <tdonohue> assigned to me
[15:38] <tdonohue> next up is my large PR: DSPR#1104
[15:38] <kompewter> [ https://github.com/DSpace/DSpace/pull/1104 ] - DS-2654: Enhanced Configurations via Apache Commons Configuration by tdonohue
[15:38] <hpottinger> tdonohue: I've added 1086 to my list of things to test
[15:39] <tdonohue> hpottinger: please feel free to add your feedback as well. thanks!
[15:39] <mhwood> I'll be testing 1104 today.
[15:39] <hpottinger> I've added 1104 to my list as well
[15:40] <tdonohue> mhwood: regarding your feedback on 1104, if we can find a way to not *REQUIRE* local.cfg in the maven-assembly, I'm OK with that. My intention was never to require it to actually be there...but if it is in the source tree, I think we should copy it over to the 'dspace-installer' directory
[15:40] <mhwood> My note was more of a heads-up: if you do strange things with local.cfg, Maven has a fit.
[15:40] <mhwood> I don't consider that a reason not to merge this.
[15:41] <tdonohue> makes sense
[15:41] <KevinVdV> tdonohue, mwood: I would like to have a least a default file in which to buil DSpace that supports maven filtering
[15:41] <mhwood> It's a Maven bug.
[15:42] <KevinVdV> But I need to run now, if some PRs need my attention please email them to me. I’ll try to close in on the ones assigned to me.
[15:42] <tdonohue> KevinVdV: I agree. I just never intended to *require* that the local.cfg file is there. But, if it is there, then Maven should use it, etc
[15:42] <mhwood> I'm not prepared to ask for changes to the way local.cfg is handled right now. I may have some suggestions for improvement later when I've had time to study the matter.
[15:42] <KevinVdV> In that case great !
[15:42] <mhwood> But my comments to date should not hold up adoption of this PR.
[15:43] <tdonohue> sounds fine. I think 1104 is ready to go, but I readily admit there may be more ways we can streamline/enhance things post 1104 getting in.
[15:43] <KevinVdV> Follow up pull requests to fix bugs can always be made.
[15:43] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[15:43] <tdonohue> So, I'll wait on further testers for 1104. Plus, if we can get other PRs in first, that's OK as it lessens the number of PRs that 1104 will potentially break
[15:44] <mhwood> So I will try to have a vote to put on this today.
[15:44] <tdonohue> moving along for now then... DSPR#1159
[15:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1159 ] - DS-79 Assetstore to support different implementations, including S3 by peterdietz
[15:44] <mhwood> Already +1 from me after testing.
[15:45] <mhwood> This code has been brewing for a long time. I worked with an earlier version and liked it then too.
[15:46] <tdonohue> 1159 is a high priority I think. We really should have this merged, plus I like the fact that it removes old crud (like SRB support) which we haven't really supported for some time
[15:47] * peterdietz (uid52203@gateway/web/irccloud.com/x-idhenxjsyzltulni) has joined #duraspace
[15:47] <mhwood> And if somebody really needs SRB, it can always be reinstated as a plugin, perhaps even out-of-tree.
[15:47] <mhwood> peterdietz, we are discussing DS-79 right now!
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-79 ] - [DS-79] Pluggable storage / S3 - ID: 2561561 - DuraSpace JIRA
[15:47] <tdonohue> I'll give this one a spin as well...especially since I'm familiar with S3, and can probably hook this up to an S3 backend for some basic testing.
[15:48] <peterdietz> Hi All. Any questions? I can read the log. Hardy just pulled me in
[15:49] <hpottinger> it looks like 1179 is one +1 away
[15:49] <tdonohue> peterdietz: I don't have any specific questions. Though, I do think we need a JIRA ticket which tracks the removal of SRB support, which we can "link up" to this ticket once it's merged
[15:49] <mhwood> Is the checksum stuff sorted?
[15:49] <peterdietz> Oh.. It was pending something about the checksum.. Right.. I haven't touched this in the past week. So that is the merge-button blocker
[15:50] <mhwood> Seems like the attempted fix should be backed out and continued separately?
[15:50] <tdonohue> peterdietz: any estimated timeline on checksum stuff?
[15:50] <tdonohue> Or, yes...the checksum issues could be extracted into a separate ticket/issue
[15:51] <peterdietz> Yep, yank out any checksum code repair attempt, and let that be a separate effort.
[15:51] <mhwood> DS-2863
[15:51] <kompewter> [ https://jira.duraspace.org/browse/DS-2863 ] - [DS-2863] Checksum checker errors out with services refactor - DuraSpace JIRA
[15:51] <tdonohue> peterdietz: sounds good. any timeline on doing that? so we can work towards final testing & merger?
[15:52] <peterdietz> Hard to say. I'll have to dissappear to the bat-cave to get some more work done. Been buried in other projects and support
[15:52] <peterdietz> But, I'll try to commit to getting it wrapped up this week.
[15:53] <tdonohue> peterdietz: wrapping it up this week would be great. I plan to give it a spin (this week), so hopefully we can get this merged as soon as the checksum stuff gets pulled out
[15:54] <tdonohue> Ok, so we have some next steps on that feature. great. I'm going to move along in the essence of time here
[15:55] <tdonohue> the next three features are all tightly intertwined (based on the same core framework): DSPR#1160 , DSPR#1162 and DSPR#1163
[15:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/1160 ] - DS-2876 Framework for importing external metadata by jonas-atmire
[15:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/1162 ] - DS-2877 Import of ScienceDirect metadata including embargo and linking to or embedding of the final version by LetitiaMukherjee
[15:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/1163 ] - DS-2880: Pubmed integration into XMLUI submission by rradillen
[15:55] <hpottinger> peterdietz: if you want testers after you make your revision, ping us, you know how to find us
[15:55] <tdonohue> The framework is in 1160...and two implementations are 1162 (ScienceDirect) and 1163 (PubMed)
[15:55] <peterdietz> Bat Signal spotlight in the city of Gotham?
[15:56] <hpottinger> we're always here
[15:57] <tdonohue> So, with these three...it seems like 1160 mainly needs a code review...and then 1162 and 1163 can be used to actually test it out for specific use cases
[15:57] <mhwood> There was discussion of overlap with BTE, as I recall?
[15:58] <hpottinger> I think there were questions raised, were they answered?
[15:58] <tdonohue> mhwood: yes, correct. See DS-2876 which notes that in 6.0, BTE would be for JSPUI, and this new framework would be for XMLUI. Then in 7.0, we'd have to choose one.
[15:58] <kompewter> [ https://jira.duraspace.org/browse/DS-2876 ] - [DS-2876] Framework to better support metadata import from external sources - DuraSpace JIRA
[15:58] <mhwood> A BTE developer responded and seemed interested in harmonizing them somehow. I think for now the question is sort-of settled?
[15:59] <mhwood> So we have a year to bring them together or pick one.
[15:59] <hpottinger> seems fair enough, we'll have to pick one with the new UI anyway
[15:59] <tdonohue> The questions are "sort-of-settled". Each framework is specific to ONE UI. The BTE developers seem to actually like the direction of this new framework (from what I've heard).
[16:00] <tdonohue> correct...we'll have the next year to settle on which one will be used in the "new UI"
[16:00] <tdonohue> (and from the response from BTE, it sounds like this new framework may have the advantage, as long as the BTE use cases can be moved over to it, etc)
[16:01] <mhwood> So right now this contribution improves feature parity between our old UIs. That sounds positive.
[16:01] <hpottinger> so, 1160, 1162, 1163 all need testing
[16:02] <tdonohue> correct. These three now need code review & testing. 1160 is mostly about code review (as it's a framework and hard to "test" standalone)... but 1162 and 1163 provide opportunities to test out the framework for specific needs
[16:02] <hpottinger> the dance card is filling up
[16:03] <tdonohue> So, is anyone interested in spending some time testing one (or more) of these three?
[16:03] <hpottinger> I've jotted all three PRs down on my list of things to test this week
[16:04] <hpottinger> though, frankly, testing will take a back seat to work I'm doing on a next release of my repository
[16:05] <mhwood> 1160 seems to be 100% new code, so it would be hard for it to break anything.
[16:05] <tdonohue> makes sense. Yes, I can also try to get to these..but, they'll likely take a back seat for me (for testing other feature PRs, etc) as well
[16:08] <tdonohue> Ok, since we just have a few more..we'll leave these PRs for now (and try to get them tested ad hoc)
[16:09] <tdonohue> That leaves just two more PRs in our listing... first up, DSPR#1166
[16:09] <kompewter> [ https://github.com/DSpace/DSpace/pull/1166 ] - DS-2888: JSPUI: Add language tags to submission edit metadata step by pnbecker
[16:10] <tdonohue> This change seems reasonable to me. It's only for the JSPUI by default, but seems like it could be relatively easily adapted to the XMLUI too
[16:10] <mhwood> That's my reading as well.
[16:11] <mhwood> It's +1 already....
[16:11] <tdonohue> helix84 added a few comments to pbecker in the PR itself. None of them are show stoppers though
[16:11] <tdonohue> The code itself looks OK to me though
[16:12] <hpottinger> anyone want to do a "+1 by inspection?"
[16:13] <pbecker> we are already preparing the documentation
[16:13] <pbecker> I will answer helix comments in the PR.
[16:14] <tdonohue> I added a +1 by inspection and seconded helix84's notes
[16:15] <tdonohue> One more feature PR, so I'm going to push through to this last one... DSPR#1173
[16:15] <kompewter> [ https://github.com/DSpace/DSpace/pull/1173 ] - DS-2894:REST Call to return Optimized Hierarchy by terrywbrady
[16:16] <tdonohue> hpottinger & peterdietz were specifically called out in this PR :)
[16:16] <mhwood> 99% new code, 1% new configuration.
[16:16] <tdonohue> the concept here seems good to me. It just seems like it needs a test. The overall code also seems reasonable
[16:17] <hpottinger> on my list of things to test
[16:18] <peterdietz> I haven't been able to look into this one previously.
[16:18] <tdonohue> I still admit to not liking these "bypass auth" settings in these REST API features...but I understand why terry-b wants them (because REST doesn't support all our AuthN options)
[16:18] <peterdietz> Perhaps a minor thing. Instead of HierarchyRepository, it could be HierarchySite...
[16:19] <peterdietz> Yeah. I'm not a fan of the bypasses.
[16:19] <mhwood> We can fix that later by fixing REST authN in general.
[16:20] <tdonohue> mhwood: true
[16:20] <peterdietz> We don't have a DSO for Repository, but we do have a DSO for Site. (Which I'm hoping to advance)
[16:20] <hpottinger> KevinVdV mentioned he might have some authN work to review...
[16:20] <tdonohue> peterdietz: that's a good point. Could you add that feedback to the PR. It's a tiny thing, but probably necessary
[16:21] <mhwood> It would make the code easier to think about, keeping the names consistent. A small matter but a reasonable one.
[16:21] <tdonohue> +1
[16:23] <mhwood> So, what to do?
[16:23] <tdonohue> This one just needs minor changes (rename) and testing. Looks like peterdietz said he'd test it in the PR itself
[16:24] <mhwood> We have a tester.
[16:24] <mhwood> Another.
[16:25] <mhwood> Onward?
[16:25] <tdonohue> Sorry, I was adding a comment as well :)
[16:26] <tdonohue> Ok. That's actually the entirety of our Feature PR list (all 13 of them)
[16:26] <hpottinger> 27 improvements
[16:26] <tdonohue> We could move on to our list of "improvements" if folks have more time though
[16:27] <mhwood> We're less than halfway through "Jira" hour.
[16:27] <hpottinger> I do, brb in a moment
[16:27] <tdonohue> Ok, let's just continue here then...we'll use up more of the JIRA backlog hour then, and keep chugging away. If anyone needs to depart, feel free, you can always read these logs later
[16:27] <hpottinger> before I wander off, we haven't talkd about a schedule
[16:28] <tdonohue> hpottinger: oh, right :) Yes, let's press pause for a moment
[16:28] <tdonohue> So, regarding our Feature Freeze schedule. It's rather obvious to me that we are *not* currently under a "freeze", nor can we freeze until we have a final decision on the 13 outstanding feature PRs.
[16:29] <tdonohue> It seems like, of those 13, we have a fair number that are nearly ready (just need testing & final verification), but that's going to take some time. It's probably not likely to expect them all to be "in" by end of this week, or even end of next week (with the holiday pending)
[16:30] <tdonohue> While, I hate to push back so far, I don't see much option other than to delay freeze until we can get these 13 reviewed & ready. I think we need to push hard to get them finished up though, but it's unlikely (in my mind) that'll happen before the new year
[16:31] <tdonohue> Do others agree / disagree?
[16:31] <mhwood> That seems likely to me.
[16:31] <tdonohue> Essentially, I'm wondering if our new "freeze" date should be something like January 7/8? I don't see any way around pushing back to then
[16:31] <pbecker> +1
[16:32] <peterdietz> I'd like the features that have been committed, and are on the finish line to be able to go that final inch, and get in. So, altering the schedule if neccessary to allow that happen is good
[16:33] <mhwood> That seems reasonable. We had two releases running in parallel *plus* the UI Challenge *plus* stamping out fires from Services. There simply hasn't been enough time to do it all.
[16:33] <hpottinger> +1
[16:33] <hpottinger> (and, you know, rolling out the last release into production)
[16:34] <tdonohue> Ok, I'll adjust our timelines for the 6.0 release again then. I'll update our Freeze to be January 8 and push back everything else appropriately
[16:35] <tdonohue> The reality is we had a massive buffer between RC1 and Testathon (to avoid holidays) anyway...so this change shouldn't push back our overall deadlines too much...maybe just by a week or two.
[16:36] <tdonohue> Ok, so we'll move back into PR review mode now...jumping over to our list of "improvements"
[16:36] <tdonohue> https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+milestone%3A6.0+label%3Aimprovement
[16:36] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+milestone%3A6.0+label%3Aimprovement
[16:36] <tdonohue> we'll start at the very bottom (page 2), with DSPR#799
[16:36] <mhwood> Picky point of terminology: usually a "feature freeze" means "no new features will be *considered*". What we're in now is the period after which all new features which have been accepted are in the shared code and will ship.
[16:37] <kompewter> [ https://github.com/DSpace/DSpace/pull/799 ] - DS-2366 Allow dspace.dir to be filtered by mdiggory
[16:37] <hpottinger> isn't "feature freeze" the "no merge zone"?
[16:38] <mhwood> Does this one even apply, if configuration goes in?
[16:38] <tdonohue> mhwood: that's not entirely accurate. We tend to have a "feature PR deadline" (which is our "no new features will be *considered*" deadline), and a "feature freeze" (which is our "no new features will be added to the codebase for next release" deadline)
[16:39] <mhwood> OK, that's the terms we use. I'll quiet down now. :-)
[16:39] <tdonohue> We're currently between those two...So, we are not considering any *new* features (additional to the 13 PRs), but we need to finalize which will be *in* 6.0
[16:39] <tdonohue> Back to our 'improvement' reviews... DSPR#799
[16:40] <kompewter> [ https://github.com/DSpace/DSpace/pull/799 ] - DS-2366 Allow dspace.dir to be filtered by mdiggory
[16:40] <mhwood> Merge conflict, possible typo, awaiting author.
[16:41] <tdonohue> much of this will be obsolete with Commons Config stuff. Or at least, I see no reason for this change (as I noted in a comment as well)
[16:41] <tdonohue> I'd recommend this get rescheduled and/or possibly closed
[16:42] <tdonohue> I'm going to close it actually..it has a ton of old stuff in it (LNI too)...it's very outdated and I don't understand why it is needed
[16:42] <mhwood> I'm thinking: close it and reopen if we misunderstood something (or Configuration doesn't go in for some reason).
[16:43] <helix84> After a brief look at why of #994 fails, it actually correctly identifies bogus configuration we've been using as default: https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L763-L766
[16:43] <kompewter> [ DSpace/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L763-L766
[16:43] <helix84> commenting it out trips another test case
[16:44] <helix84> I recommend we should just set some actual field as default. What would be a sensible DC/DCTERMS field to store embargo terms?
[16:44] <mhwood> I think there isn't one, but we can invent one in our own namespace.
[16:44] <tdonohue> helix84: there are none. Which is why those strange defaults are in the configs
[16:45] <helix84> moreover, this old embargo plugin was subject to removal discussion, as there is now a more specialized resource-policy based embargo
[16:45] <tdonohue> helix84: yes, I agree..this is the older embargo stuff which likely should get removed at some point
[16:46] <helix84> there's no better time than now :) https://jira.duraspace.org/browse/DS-2588
[16:46] <kompewter> [ [DS-2588] Remove or merge pre-3.0 Embargo functionality with new Embargo - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2588
[16:46] <kompewter> [ https://jira.duraspace.org/browse/DS-2588 ] - [DS-2588] Remove or merge pre-3.0 Embargo functionality with new Embargo - DuraSpace JIRA
[16:46] <helix84> gotta run, bye
[16:46] <tdonohue> So, maybe it's also possible just to fix/change the code to ignore those settings if they are the default values of "SCHEMA.ELEMENT.QUALIFIER"
[16:46] <tdonohue> helix84: feel free to volunteer :) It just needs someone to do the extraction work
[16:47] <mhwood> Remove values, comment properties, ignore nulls?
[16:48] <tdonohue> mhwood: something like that would also work
[16:48] <mhwood> If we give a sample value, that sort of implies that it might work.
[16:49] * pmarrone (~pmarrone@proxy3.psi.unc.edu.ar) Quit (Remote host closed the connection)
[16:49] <tdonohue> yep. In any case, we need a volunteer here to fix this or extract it (2588)
[16:50] <tdonohue> We're running short on time here...but I want to try and make it through a few other improvement PRs, if possible
[16:50] <tdonohue> next from the bottom is DSPR#800
[16:50] <kompewter> [ https://github.com/DSpace/DSpace/pull/800 ] - DS-2367 Improve BitstreamReader Performance and Caching behavior in XMLUI by mdiggory
[16:51] <tdonohue> which has a merge conflict...it also has the changes in #799 (which was just closed) embedded into it (yuck)
[16:52] <tdonohue> The idea is nice, but this needs a lot of work.
[16:52] <mhwood> Too old, code has moved on? Needs work.
[16:54] <hpottinger> I like this work, but, you're right, it needs love
[16:54] <tdonohue> I added a comment. I'll leave it for now, in case someone can bring it forward quickly. But, likely this needs to be rescheduled
[16:54] <hpottinger> I'd be willing to be they have newer code
[16:54] <hpottinger> s/be/bet/
[16:54] <kompewter> hpottinger meant to say: I'd bet willing to be they have newer code
[16:55] <hpottinger> darn it kompewter, do what I mean!
[16:55] <tdonohue> Ok, moving along, the next one is the same scenario: DSPR#802
[16:55] <mhwood> Next one has merge conflict and *two* embedded previous PRs.
[16:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/802 ] - DS-2369 Add Support for Created and Modified timestamps on Bitstreams by mdiggory
[16:55] <mhwood> It's a good idea I don't want to lose, but it needs some cleanup.
[16:56] <tdonohue> agreed. I added a comment again, to try and get movement here
[16:56] <hpottinger> needs love, move on :-)
[16:57] <tdonohue> next, DSPR#806
[16:57] <kompewter> [ https://github.com/DSpace/DSpace/pull/806 ] - DS-2371 item export without bitstreams from community by akinom
[16:57] <tdonohue> another merge conflict
[16:57] <mhwood> Likely needs Services update.
[16:57] <tdonohue> yep
[16:58] <hpottinger> doesn't pbecker have another export without bitstreams feature?
[16:58] <pbecker> hpottinger: already looking for it
[16:58] <mhwood> DS-2315?
[16:58] <kompewter> [ https://jira.duraspace.org/browse/DS-2315 ] - [DS-2315] export without bitstreams - DuraSpace JIRA
[16:59] <hpottinger> so... possibly we don't even need 806, and it has a merge conflict
[17:00] <tdonohue> huh, that looks like the same idea as DS-2371?
[17:00] <kompewter> [ https://jira.duraspace.org/browse/DS-2371 ] - [DS-2371] exclude bitstreams from item export + export items from community - DuraSpace JIRA
[17:00] <tdonohue> although 2371 adds an "export" from community it seems?
[17:00] <pbecker> There was a chat where mhwood and I was asked about our feature freeze.
[17:00] <pbecker> Someone had closed his old PR and opened up a new rebased one and I added the labels.
[17:01] <pbecker> I think it was akinom, but I can't find it right now.
[17:01] <pbecker> hpottinger: I don't have a export without bitstreams (as far as I know ;-))
[17:02] <hpottinger> sory, pbecker I'm a poor confused person
[17:02] <tdonohue> the last comment to 2371 (from petya) notes that 2371 should just use 2315 and add in the "export from community" feature.
[17:02] <mhwood> So some parts of 2371's function have already been merged. Probably this needs recasting to pull out the other feature.
[17:02] <tdonohue> yes, I think that's right, mhwood
[17:03] <pbecker> Here it is: DSPR#1210
[17:03] <kompewter> [ https://github.com/DSpace/DSpace/pull/1210 ] - DS-2315: export Simple Archive Format without bitstreams by kohts
[17:04] <pbecker> it was merged by helix and addresses DS-2315 as DSPR#806 does.
[17:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2315 ] - [DS-2315] export without bitstreams - DuraSpace JIRA
[17:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/806 ] - DS-2371 item export without bitstreams from community by akinom
[17:04] <pbecker> Shall I add a comment to 806 and close it?
[17:05] <tdonohue> pbecker I just did that: DSPR#806
[17:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/806 ] - DS-2371 item export without bitstreams from community by akinom
[17:05] <pbecker> great, thanks
[17:06] <tdonohue> I'm going to stop there for today (as we are over time for JIRA backlog now).
[17:07] <tdonohue> Just a quick question for folks still around. Are you all going to be working next Weds (Dec 23)? I'd like to have a DevMtg then, if so. But, if no one will show, then obviously there's no need :)
[17:08] <mhwood> I'm off work but may be able to appear here anyway.
[17:08] <hpottinger> If I'm not at work I'll be home watching kids so I can attend an IRC meeting
[17:08] <pbecker> I'm off work and as it is a late meeting, I won't be able to join.
[17:11] <tdonohue> Ok. Well, we'll tentatively aim for one then, just to touch base. But, I'll let you know :)
[17:11] <mhwood> OK, thanks.
[17:56] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:53] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
[18:55] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[19:13] * terry-b (~chrome@174-24-248-234.tukw.qwest.net) has joined #duraspace
[19:47] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:00] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) Quit (Quit: srobbins)
[22:44] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
[23:19] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.