Timestamps are in GMT/BST.
[6:37] -karatkievich.freenode.net- *** Looking up your hostname...
[6:37] -karatkievich.freenode.net- *** Checking Ident
[6:37] -karatkievich.freenode.net- *** Found your hostname
[6:37] -karatkievich.freenode.net- *** No Ident response
[6:37] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:37] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:37] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:02] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:59] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:45] * dyelar (~dyelar@129.237.146.129) has joined #duraspace
[14:53] <DSpaceSlackBot> <tdonohue> @here : Reminder that our DSpace DevMtg starts here at the top of the hour. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-07-26
[14:53] <kompewter> [ DevMtg 2017-07-26 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-07-26
[15:00] <DSpaceSlackBot> <tdonohue> Hello all @here. Welcome. It's time for our DSpace DevMtg (agenda linked above)
[15:01] <DSpaceSlackBot> <tdonohue> As discussed last week, we'll be keeping this meeting concentrated a bit more on DSpace 6.x maintenance (though other topics are welcome should we have time). I'd encourage folks to bring topics to this meeting that you want to discuss, as often the agenda is a bit light (as it is today)
[15:02] <DSpaceSlackBot> <tdonohue> Let's start though with a quick roll call to be sure others are here / paying attention today ;)
[15:02] <DSpaceSlackBot> <mwood> Here
[15:02] <DSpaceSlackBot> <terrywbrady> here
[15:03] <DSpaceSlackBot> <tdonohue> Well, at least a few of us are here :slightly_smiling_face: Good to see.
[15:03] <DSpaceSlackBot> <tdonohue> Ok, a few notes are at the top of the agenda to kick things off
[15:04] <DSpaceSlackBot> <tdonohue> First, I mentioned this in dev Slack, but we now have the capability to assign JIRA tickets to *any* developer (not just a Committer). However, you have to ask to be added to our "dspace-developer" group in JIRA to get this capability. So, please just ping me if you want to be added, or know someone who does
[15:05] <DSpaceSlackBot> <tdonohue> Next, @bram (and perhaps a few others) noted that demo.dspace.org hasn't been upgraded to DSpace 6.1 yet. I admit, I haven't had a chance to do this (and may not get to it this week). If there's anyone out there that'd like to help out and do this upgrade, please let me know
[15:06] <DSpaceSlackBot> <tdonohue> I doubt it'll be hard, it's just a matter of pulling down the latest code, rebuild & redeploy
[15:06] <DSpaceSlackBot> <tdonohue> And the process is documented here: https://wiki.duraspace.org/display/DSPACE/demo.dspace.org+Notes
[15:06] <kompewter> [ demo.dspace.org Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/demo.dspace.org+Notes
[15:07] <DSpaceSlackBot> <tdonohue> Ok, not hearing a volunteer. Hopefully I can get to this next week or something. Otherwise, it'll likely wait until someone else gets annoyed by it enough to spend 30mins or so on it
[15:08] <DSpaceSlackBot> <tdonohue> That was it for the two quick topics I had for today. Were there 6.x tickets (for a possible 6.2 at some point) that anyone wanted to discuss today?
[15:08] <DSpaceSlackBot> <terrywbrady> DS-3602
[15:08] <kompewter> [ https://jira.duraspace.org/browse/DS-3602 ] - [DS-3602] Bitstream statistics are not shown after a migration to 6.x - DuraSpace JIRA
[15:09] <DSpaceSlackBot> <terrywbrady> We have a PR for 7x (as of now) that changes the solr schema. There is another PR now ready for retest and merge
[15:10] <DSpaceSlackBot> <terrywbrady> There is some code StatisticsDataVisits that is in need of a re-factor. I made the most minimal changes that I could to resolve a bug in the reporting of legacy stats
[15:12] <DSpaceSlackBot> <tdonohue> Ok, looks like you pinged @aroman again on this, which is good as he seemed to be a good tester
[15:13] <DSpaceSlackBot> <hpottinger> hey there, sorry, distracted by work work, but, I'll update demo, you know, 6.1 was a security release and all.
[15:13] <DSpaceSlackBot> <tdonohue> Thanks @hpottinger!
[15:13] <DSpaceSlackBot> <terrywbrady> If we can re-factor the stats reporting code, it would be helpful to report descendant DSO views when looking at usage stats for a Coll or Comm. I added a ticket for that.
[15:14] <DSpaceSlackBot> <terrywbrady> https://jira.duraspace.org/browse/DS-3657
[15:14] <kompewter> [ [DS-3657] Usage statistics for a community/collection should show counts of bitstream views and item views - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3657
[15:14] <kompewter> [ https://jira.duraspace.org/browse/DS-3657 ] - [DS-3657] Usage statistics for a community/collection should show counts of bitstream views and item views - DuraSpace JIRA
[15:14] <DSpaceSlackBot> <tdonohue> @terrywbrady : yes, that seems like a good idea in general...though I'm not sure how high priority that is for DSpace 7 yet (until we get REST API endpoints for stats & a new UI for them)
[15:14] <DSpaceSlackBot> <tdonohue> But, it's good to have a ticket there
[15:15] <DSpaceSlackBot> <terrywbrady> That makes sense. I am unclear if this old code lives on
[15:16] <DSpaceSlackBot> <tdonohue> DSpace 7 is essentially the same underlying code in DSpace 6...so, I'm sure the code lives on there... it's just a matter of re-surfacing it through the new DSpace 7 REST API (so that it becomes more easily testable, etc)
[15:17] <DSpaceSlackBot> <terrywbrady> Fyi, I have integrated DSpace 6.1 with our local changes on my test server. I plan to run through my test plan. I will be reporting any errors that I uncover.
[15:17] <DSpaceSlackBot> Action: tom_desair joins the meeting
[15:19] <DSpaceSlackBot> <tdonohue> So, @terrywbrady regarding your 6.x fix, I'd like to see if we can get @aroman to test it again...and maybe someone else here can help with a code review too. At a glance the PR loooks reasonable: DSPR#1782
[15:19] <kompewter> [ https://github.com/DSpace/DSpace/pull/1782 ] - [DS-3602] Ensure Consistent Use of Legacy Id in Usage Queries by terrywbrady
[15:20] <DSpaceSlackBot> <terrywbrady> @tom_desair , I know you tested this before. If you have a chance, could you do a re-test as well?
[15:21] <DSpaceSlackBot> <tom_desair> Yes that shouldn’t be a lot of work. I’ll also test the “duplicate” facet issue reported there.
[15:21] <DSpaceSlackBot> <tdonohue> And, just to check in, it sounds like we've verified that we definitely *don't* need the bigger Solr Schema change in 6.x? Just want to be sure that we know exactly what should be in 6.2 vs 7.0
[15:21] <DSpaceSlackBot> <terrywbrady> I wish I had a stronger opinion on the matter...
[15:22] <DSpaceSlackBot> <tdonohue> I'm fine either way. If it makes your life easier, push for it @terrywbrady . I just don't have an opinion myself (cause I don't tend to use these stats, TBH).
[15:22] <DSpaceSlackBot> <terrywbrady> I am eager to get the complete solution in place, but it would add complexity to the upgrade process. I guess I am looking for someone else to say yes lets do it now.
[15:22] <DSpaceSlackBot> <tdonohue> I'd only develop a "strong opinion" if we found that the lack of the schema change actually *breaks* something in 6.x
[15:23] <DSpaceSlackBot> <terrywbrady> That makes sense. I will keep an eye out for related errors as I run my tests locally.
[15:23] <DSpaceSlackBot> <tdonohue> Thanks, @terrywbrady, sounds good. And thanks for being willing to run 6.1 through your tests and reporting back
[15:24] <DSpaceSlackBot> <tom_desair> Agreed if the “consistent use of legacy id” fix repairs the behaviour in 6, I would postpone the schema change to 7
[15:24] <DSpaceSlackBot> <terrywbrady> Thanks. I appreciate the confirmation of our plan
[15:25] <DSpaceSlackBot> <tdonohue> Any other 6.x tickets that anyone wants to discuss today?
[15:26] <DSpaceSlackBot> <tom_desair> I just wanted to report that there are two Hibernate bugs in 6.1: https://jira.duraspace.org/browse/DS-3648 and https://jira.duraspace.org/browse/DS-3656
[15:26] <kompewter> [ [DS-3648] XMLUI Batch Import Failure - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3648
[15:26] <kompewter> [ [DS-3656] DOIOrganiser CLI does not change the database anymore - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3656
[15:26] <kompewter> [ https://jira.duraspace.org/browse/DS-3648 ] - [DS-3648] XMLUI Batch Import Failure - DuraSpace JIRA
[15:26] <kompewter> [ https://jira.duraspace.org/browse/DS-3656 ] - [DS-3656] DOIOrganiser CLI does not change the database anymore - DuraSpace JIRA
[15:27] <DSpaceSlackBot> <tdonohue> @tom_desair: yes, thanks for the note. Sounds like you are still working on 3648 (from the comments). Is 3656 looking for review/tests now?
[15:28] <DSpaceSlackBot> <tom_desair> Correct. I’m still investigating DS-3648 more. Hibernate can really drive me crazy sometimes :)
[15:28] <kompewter> [ https://jira.duraspace.org/browse/DS-3648 ] - [DS-3648] XMLUI Batch Import Failure - DuraSpace JIRA
[15:28] <DSpaceSlackBot> <tom_desair> But at least the hibernate layer will be stable when we release DSpace 7 ;)
[15:29] <DSpaceSlackBot> <tdonohue> Also, are we sure (with all the caching changes in 6.1) these same sorts of issues won't pop up elsewhere? (I know we can never be 100% sure, but this is an opportunity perhaps to look back at the past changes for similar issues)
[15:30] <DSpaceSlackBot> <tdonohue> I'd just rather we do some due diligence to dig deeper now and fix these in a 6.2 together...instead of discovering a new one every few months ;)
[15:31] <DSpaceSlackBot> <terrywbrady> Once demo.dspace.org is updated, is there some way to ask the community to run through test scenarios (as was done for 6.0)?
[15:31] <DSpaceSlackBot> <tom_desair> Agreed. But it would help if more people would help testing stuff before we cut a release and not only test the new version when the release is published.
[15:32] <DSpaceSlackBot> <hpottinger> Best way to ask the community is to, erm, ask the community :slightly_smiling_face:
[15:32] <DSpaceSlackBot> <tom_desair> Maybe for the next release, we should cut a 6.2-rc and then ask people to test that release candidate.
[15:33] <DSpaceSlackBot> <tdonohue> @terrywbrady : we could ask DCAT that question specifically. See if they'd be willing to do/organize a mini-Testathon
[15:33] <DSpaceSlackBot> <tdonohue> DCAT wrote up some XMLUI/JSPUI test plans, so maybe we can convince them to do another run through of those test plans
[15:34] <DSpaceSlackBot> <terrywbrady> Would it be best to do that with 6.1 or to plan for a 6.2-rc? I know 6.1 was particularly tricky with the security patches.
[15:35] <DSpaceSlackBot> <hpottinger> let's just consider 6.1 an RC for 6.2?
[15:35] <DSpaceSlackBot> <tdonohue> likely depends on the schedule for 6.2 (and who wants to lead that release). Though we could always simply update demo to the latest on the 6.x branch, in which case this question doesn't matter so much (it's like a pre-6.2-rc)
[15:36] <DSpaceSlackBot> <tdonohue> To be frank here, I won't be able to lead a 6.2 release. I do think it's important to have one, but my concentration *needs* to move to 7.0 if we are going to get that out in a semi-timely manner.
[15:36] <DSpaceSlackBot> <mwood> At some sites it would make a big difference, asking them to test vs. to install and test.
[15:37] <DSpaceSlackBot> <hpottinger> demo will be running 6.1 later toay
[15:37] <DSpaceSlackBot> <tom_desair> Publishing a Release Candidate can give a signal to the (user) community that we consider the next version to be “final”. Then they can help testing it.
[15:37] <DSpaceSlackBot> <tom_desair> I think it’s easier to motivate people to (re)test a release candidate than to find multiple testers for each PR.
[15:39] <DSpaceSlackBot> <tdonohue> I agree with that, ideally we are having them test a Release Candidate. But, to get to an RC is a very vague timeline (at least right now). So, if we are worried about certain aspects of 6.1 *now*, then waiting until 6.2-RC could (potentially) be a long wait.
[15:39] <DSpaceSlackBot> <terrywbrady> The next DCAT is 8/8. I will as Bram and Maureen if I can have some time on the agenda. Perhaps we can ask them for both.
[15:40] <DSpaceSlackBot> <tdonohue> So, the question in my mind is *when do we want this testing?* If we want it "very soon" it likely needs to simply be smaller testathon against demo.dspace.org (and/or 6.1). If we are just talking about wanting it "before 6.2", then we wait until we have a 6.2 lead & a release candidate
[15:40] <DSpaceSlackBot> <mwood> So: if we need testers to find stuff for us to fix in 6.2, then they can use demo. When we need testers for stuff we've fixed, it would be good if we can put all of that into an RC.
[15:41] <DSpaceSlackBot> <terrywbrady> I think that we ask for both. They can test 6.1 right away. That is good practice for the rc testing that we will need again.
[15:41] <DSpaceSlackBot> <tdonohue> @terrywbrady : sounds good to me
[15:42] <DSpaceSlackBot> <tom_desair> +!
[15:43] <DSpaceSlackBot> <hpottinger> (use demo later today, after I say I'm done updating it, *or* someone else runs off and does the job before me)
[15:43] <DSpaceSlackBot> <hpottinger> we need a 6.2 RC
[15:43] <DSpaceSlackBot> <tdonohue> This all sounds good to me.
[15:44] <DSpaceSlackBot> <tdonohue> RC is a vague abbreviation ;) I think @hpottinger is asking for a Release Coordinator (and not a Release Candidate)
[15:44] <DSpaceSlackBot> <hpottinger> yup yup
[15:44] <DSpaceSlackBot> <tdonohue> I agree, we need someone to lead the 6.2 release, and start to schedule that out (even with vague timelines right now)
[15:45] <DSpaceSlackBot> <mwood> I wonder if there is a good way to instrument demo so that we gather some data which might hint at good places to look for performance issues.
[15:45] <DSpaceSlackBot> <hpottinger> demo runs Yourkit
[15:45] <DSpaceSlackBot> <tdonohue> I'm not pushing too hard on that now though, as it seems like we don't have anything *yet* to go into 6.2 (just some PRs that are starting to line up). So, in the meantime, I'd just ask everyone to think about leading the 6.2 release (and/or talk to your boss about it, if you are interested)
[15:46] <DSpaceSlackBot> <tom_desair> We should also ask the community to test 6.1 so that we uncover bugs that we can fix in the 6.2 release candidate.
[15:46] <DSpaceSlackBot> <tdonohue> demo.dspace.org does run YourKit. Docs on all that are at: https://wiki.duraspace.org/display/DSPACE/demo.dspace.org+Notes#demo.dspace.orgNotes-JavaProfilingusingYourKit
[15:46] <DSpaceSlackBot> <terrywbrady> It sounds like one area where we will need some testing is in the command line scripts. Would we have any recommendations for coordinating that with community testers?
[15:46] <kompewter> [ demo.dspace.org Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/demo.dspace.org+Notes#demo.dspace.orgNotes-JavaProfilingusingYourKit
[15:46] <DSpaceSlackBot> <hpottinger> only reason I asked is there seems to be strong interest in doing a very formal 6.2, so... I infer an interest in leading 6.2 must be there somewhere...
[15:47] <DSpaceSlackBot> <terrywbrady> Hardy, can you explain what that statement means?
[15:48] <DSpaceSlackBot> <tdonohue> (I think we have several conversations going on here at once ;) I think Hardy was referring to my note about not pushing on getting a volunteer to lead 6.2 quite yet)
[15:48] <DSpaceSlackBot> <hpottinger> ^^ yes
[15:49] <DSpaceSlackBot> <tom_desair> Not exactly formal. I just think we need to find a way to motivate people to test a new release before the actual release is published (and we’re stuck with the bugs).
[15:49] <DSpaceSlackBot> <mwood> Maybe concurrently we can capture some of what people do with command line testing, to form the nucleus of an automated functional-test suite.
[15:49] <DSpaceSlackBot> <hpottinger> @mwood++ yes, MOAR TESTS!
[15:49] <DSpaceSlackBot> Action: tom_desair needs to run now.
[15:51] <DSpaceSlackBot> <tdonohue> I think these are all good ideas. I don't have immediate answers, but it makes me wonder if we should form a 6.2 Release Team (to make these decisions) or a more general 6.x Working Group (to parallel the 7.0 one)
[15:52] <DSpaceSlackBot> <terrywbrady> Maureen and Bram, In today's developer meeting, we determined that we need some community assistance with testing. The DSpace 6.1 release touched several portions of the system that would benefit from end-user testing as was done during the 6.0 testathon. Also, if/when a DSpace 6.2 release is created we would like to perform user testing on the release. Could I have a few minutes at the next DCAT meet
[15:52] <DSpaceSlackBot> about how this might work? Thanks, Terry
[15:52] <DSpaceSlackBot> <hpottinger> I do think we'll need an RT if we're going to do release candidates
[15:53] <DSpaceSlackBot> <tdonohue> In other words, I'd like to find a way to empower you all to make these decisions for 6.2 / 6.x.
[15:54] <DSpaceSlackBot> <tdonohue> Yes, I think we'd need/want a 6.2 Release Team if we want to do a more extensive release, involving a release candidate, mini-testathon, etc. We didn't do a lot of that for 6.1, as we had no release team, and were rushing to fix security issues
[15:54] <DSpaceSlackBot> <terrywbrady> This is tricky because I want to work on 7x as well.
[15:54] <DSpaceSlackBot> <hpottinger> and we don't usually do an RC for minor releases, though 6.1 did get a little big, didn't it?
[15:55] <DSpaceSlackBot> <terrywbrady> We had a high priority issue that killed the momentum that I was starting to get with 7x.
[15:56] <DSpaceSlackBot> <hpottinger> heads up, I have to run to a standup at the top of the hour
[15:57] <DSpaceSlackBot> <tdonohue> @terrywbrady : I understand the feeling. That's part of the balance I'm also having to deal with. I'm trying to help the 7.x team get moving quicker (and pull more people in), and at the same time, realizing 6.x isn't gonna just be "done"
[15:58] <DSpaceSlackBot> <hpottinger> it's OK, we make bugfix releases, we find bugs, we fix 'em, we crank out a new release
[15:58] <DSpaceSlackBot> <tdonohue> Maybe we trying and do a quick, less formal 6.2...but that involves making some compromises.. it could be something like: (1) Ask DCAT for 6.1 testing, (2) Quickly resolve any major bugs, (3) Quickly release a 6.2 (skipping a formal Release Candidate unless someone steps forward to do it)
[15:59] <DSpaceSlackBot> <hpottinger> sounds fine to me, we just iterate over that until we are all happy with the results
[15:59] <DSpaceSlackBot> <tdonohue> Staging that out to something more formal, involving a release team, and Release Candidate(s) will take much longer and require more time/effort from individuals
[15:59] <DSpaceSlackBot> <tdonohue> (even if it's "ideally" done that way)
[16:00] <DSpaceSlackBot> <hpottinger> 6.0 was a big refactor, it makes sense we'd be shaking bugs out for a while
[16:00] <DSpaceSlackBot> <mwood> Well, we have a number of issues already filed against 6_x, and we separately have some speculation that there may be as-yet-unknown performance/caching issues.
[16:01] <DSpaceSlackBot> Action: tdonohue realizes we are at the top of the hour here
[16:01] <DSpaceSlackBot> <hpottinger> oh, yes, I'll be back in about 15 minutes
[16:03] <DSpaceSlackBot> <tdonohue> Perhaps we need to pick this up next week? To summarize... it sounds like we have two options: (1) A more formal 6.2 planned release (likely requiring a release team, release candidate(s) and more effort), or (2) a quick, ad-hoc "just fix the big bugs" 6.2 release (less formal, less effort, but may not necessarily catch everything)
[16:03] <DSpaceSlackBot> <mwood> Or (3) a quick 6.2 and a longer-term 6.3.
[16:03] <DSpaceSlackBot> <tdonohue> There are pros/cons to each... but the first option definitely requires individuals here to step forward and volunteer to be on a 6.2 Release Team (of sorts)
[16:03] <DSpaceSlackBot> <tdonohue> @mwood : Yes, I was just keeping this to one release at a time. But, you are correct
[16:04] <DSpaceSlackBot> <terrywbrady> I sent a note to Bram and Maureen to chat about a mini-Testathon (to find bugs in 6.1 and to support the next release)
[16:04] <DSpaceSlackBot> <tdonohue> Thanks @terrywbrady
[16:04] <DSpaceSlackBot> <tdonohue> Ok, let's close up for today. I'll add a topic to next week's mtg about discussing 6.2 planning further (and try and summarize these discussions there)
[16:05] <DSpaceSlackBot> <tdonohue> I unfortunately have to run (too much to do this week), but if others want to continue discussion and/or do JIRA/PR reviews, you are welcome to do so (and I can always catch up later)
[16:05] <DSpaceSlackBot> <tdonohue> bye all
[16:12] <DSpaceSlackBot> <tom_desair> > it could be something like: (1) Ask DCAT for 6.1 testing, (2) Quickly resolve any major bugs, (3) Quickly release a 6.2 (skipping a formal Release Candidate unless someone steps forward to do it) I like this. But before (3) I would first publish a 6.2 release candidate that users can download and test. Then we wait for 1 or 2 week. If there is no feedback on the 6.2 release candidate, we publish the 6.2
[16:12] <DSpaceSlackBot> feedback, we fix the bugs and release 6.2.
[16:13] <DSpaceSlackBot> <tdonohue> I've already started next week's agenda... Please feel free to enhance as needed: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-08-02
[16:13] <kompewter> [ DevMtg 2017-08-02 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-08-02
[16:22] * tdonohue (~tdonohue@dspace/tdonohue) has left #duraspace
[21:03] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.