Timestamps are in GMT/BST.
[6:32] -niven.freenode.net- *** Looking up your hostname...
[6:32] -niven.freenode.net- *** Checking Ident
[6:32] -niven.freenode.net- *** Found your hostname
[6:32] -niven.freenode.net- *** No Ident response
[6:33] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:33] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:33] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:05] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:26] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:17] * misilot (~misilot@p-body.lib.fit.edu) Quit (Remote host closed the connection)
[14:17] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[14:51] <DSpaceSlackBot> <tdonohue> <here>: Reminder, our DSpace Developers Mtg starts at the top of the hour (~10mins) here. Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-10-04
[14:51] <kompewter> [ DevMtg 2017-10-04 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-10-04
[15:01] <DSpaceSlackBot> <tdonohue> <here>: Welcome! It's DSpace DevMtg time. Agenda linked above
[15:01] <DSpaceSlackBot> <pbecker> Hello fellow DSpace developers.
[15:01] <DSpaceSlackBot> <terrywbrady> hello
[15:01] <DSpaceSlackBot> <mwood> Hi
[15:02] <DSpaceSlackBot> <tdonohue> I wanted to note, as topic #1, I've decided to add a new, ongoing topic to these meetings...sharing updates from the DSpace 7 efforts. I've added subbullets to that topic (a moment ago) which detail the latest updates
[15:03] <DSpaceSlackBot> <tdonohue> To keep this brief, I'm not going to go into this in much detail. If you want great detail on DSpace 7, please join the weekly meetings (or check our notes)... and/or you can join the outreach meetings (every other week on Thurs) for higher level updates
[15:04] <DSpaceSlackBot> <tdonohue> If there are *questions* though on DSpace 7, please feel free to ask them. Otherwise, we'll move along
[15:04] <DSpaceSlackBot> <tdonohue> Ok, not seeing anyone typing, so we'll move along ;)
[15:05] <DSpaceSlackBot> <tdonohue> Another very brief topic. You may have seen the call for participants in the new Entities Working Group: https://wiki.duraspace.org/display/DSPACE/DSpace+Entities+Working+Group
[15:05] <kompewter> [ DSpace Entities Working Group - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Entities+Working+Group
[15:05] <DSpaceSlackBot> <tdonohue> I just wanted to remind folks to please add your availability to the Doodle poll if you want to attend. I also wanted to give you all a chance to ask questions if anything is unclear about the goal of this group
[15:06] <DSpaceSlackBot> <tdonohue> (One common question I've heard is whether this discussion will feed into DSpace 7 efforts. The answer right now is "i'm not sure, but it's doubtful, unless there's small things we can bring in" We're obviously trying to keep DSpace 7 moving rapidly, and this group is looking more long term)
[15:07] <DSpaceSlackBot> <tdonohue> Sounds like there are no other questions at this time. I would encourage any of you interested in CRIS, Author Profiles or even Data Model changes (in general) to join these meetings. We could use broad feedback when it comes to how we change the data model to support things like Authors, etc
[15:08] <DSpaceSlackBot> <mwood> It would be good for the two groups to remain aware of each other's work.
[15:08] <DSpaceSlackBot> <mwood> There may be opportunities for small measures to avoid re-work.
[15:08] <DSpaceSlackBot> <tdonohue> :+1: Definitely, @mwood. Both Atmire & 4Science are involved with both groups. As am I. There will definitely be some overlap here in membership, etc
[15:09] <DSpaceSlackBot> <tdonohue> I just wanted to be clear that we aren't creating this group to change the scope of DSpace 7. Rather, it's goal is to help us roadmap out *how* to start to make these bigger (data model) changes, and whether any of that could inform DSpace 7, etc
[15:10] <DSpaceSlackBot> <mwood> Right. New UI is a big enough job already!
[15:10] <DSpaceSlackBot> <tdonohue> Ok, moving right along then. The third topic likely will take a bit more time. DOI Field discussions
[15:11] <DSpaceSlackBot> <tdonohue> There were discussions a week or so ago about where to store DOIs in Slack. The main folks involved were @pbecker
[15:11] <DSpaceSlackBot> <tdonohue> @mwood and I.
[15:11] <DSpaceSlackBot> <tdonohue> We felt it would be good to bring this to a bigger discussion...
[15:12] <DSpaceSlackBot> <tdonohue> @pbecker did you want to summarize this a bit? I'm trying to refresh myself here too
[15:12] <DSpaceSlackBot> <pbecker> After two weeks thinking about that, I still believe it would be good to change the place where we store DOIs DSpace generates. I would like to move toward dc.identifier.doi and I would like to to this within a FlayWay migration.
[15:12] <DSpaceSlackBot> <pbecker> We are currently putting DOIs DSpace generate to dc.identifier.uri.
[15:13] <DSpaceSlackBot> <pbecker> We do this for histroical reasons:
[15:13] <DSpaceSlackBot> <pbecker> 1.) Handles were put in the same place.
[15:13] <DSpaceSlackBot> <pbecker> 2.) we were using the form http://dx.doi.org/10... longtime before Crossref followed us ;) and recommended to store DOIs as https://doi.org/10....
[15:14] <DSpaceSlackBot> <pbecker> So when we developped DOI generation we thought "http://dx.doi.org" is a doi in a uri form an put it to dc.identifier.uri.
[15:14] <DSpaceSlackBot> <mwood> Meanwhile the EZID DOI code stores DOIs as dc.identifier, for reasons that I don't recall. At the least, all of our Identifier sources should be consistent.
[15:14] <DSpaceSlackBot> <pbecker> +1
[15:15] <DSpaceSlackBot> <pbecker> What we need to discuss:
[15:15] <DSpaceSlackBot> <pbecker> a) is dc.identifier.doi the right place?
[15:15] <DSpaceSlackBot> <pbecker> b) if so, will we do this as Flyway script that runs automatically?
[15:15] <DSpaceSlackBot> <pbecker> c) when do we want to change this?
[15:16] <DSpaceSlackBot> <mwood> Also, I feel that we should ensure that identifiers generated by DSpace itself are *not* mixed in the same field with identifiers submitted by users.
[15:16] <DSpaceSlackBot> <pbecker> d) do we want to discuss where to store DOIs others were generating? E.g.: a publisher publishes an article, DSpace gets the preprint, where should the publisher's doi be stored?
[15:16] <DSpaceSlackBot> <pbecker> anything else?
[15:18] <DSpaceSlackBot> <pbecker> My personal point of view: a) yes, dc.identifer.doi is the place I would prefer. b) I would love to do that, but we should ask DCAT what they think. It is the first time (as far as I know) we would change metadata that is listed in the itemview. c) next major release => DSpace 7 d) I don't want to discuss this now, I would see that as part of the new data model and out of our scope for the moment.
[15:19] <DSpaceSlackBot> <tdonohue> I think these are all good questions. I'm actually wondering right now if we should answer these ourselves, or if we bring this question to DCAT for feedback? I think `dc.identifier.doi` is the best place we have right now. But, I'm less certain if folks would like us automating this, or if they'd want freedom to decide (based on local policies) whether to migrate all DOIs to `dc.identifier.doi` or not.
[15:20] <DSpaceSlackBot> <tdonohue> Personally, I'd *like* to automate this (as it's easier to manage if we standardize where DOIs are). But, if DCAT pushes back, we may have to think about other options.
[15:21] <DSpaceSlackBot> <mwood> I'm concerned that, while dc.identifier (used by the submission form) is part of QDC, dc.identifier.* are not.
[15:21] <DSpaceSlackBot> <terrywbrady> I think it makes sense to ask DCAT.
[15:21] <DSpaceSlackBot> <tdonohue> And it sounds like @pbecker and I typed essentially the same thing. I agree with him ;)
[15:22] <DSpaceSlackBot> <terrywbrady> I am on the fence about automating the migration in the Flyway setup. I think it could be run as an optional install instruction. I do not feel that strongly about this opinion.
[15:22] <DSpaceSlackBot> <bollini> I'm in favor to move the doi *generated by dspace* automatically in the place where the new generated doi will be stored. Please avoid over engineering, we can add configuration options when requested
[15:23] <DSpaceSlackBot> <bollini> it is a completely different story for DOI manually input and stored whatever they want by the institution
[15:23] <DSpaceSlackBot> <mwood> I also favor automatically moving DOIs that were generated by DSpace.
[15:24] <DSpaceSlackBot> <tdonohue> Can we tell (programmatically) which DOIs are "generated by DSpace" vs manually entered?
[15:24] <DSpaceSlackBot> <bollini> I hope so... we should have dedicated doi table for the conversation with the DOI registration agency
[15:24] <DSpaceSlackBot> <bollini> not sure about all the different implementations (EZID, datacite)
[15:25] <DSpaceSlackBot> <mwood> If you use DataCite, yes; if EZID, the best we can do is hope that pattern matching will succeed.
[15:25] <DSpaceSlackBot> <pbecker> For DOIs manually inserted I've seen dcterms.bibliographicCitation.doi and I think dc.type.version or so.
[15:26] <DSpaceSlackBot> <pbecker> We can do some pattern matching with a really high likelihood.
[15:26] <DSpaceSlackBot> <pbecker> Every doi that uses the prefix that we use to generate DOIs should be one of ours.
[15:26] <DSpaceSlackBot> <pbecker> No one else should generate DOIs using this prefix. I think that is good enough.
[15:26] <DSpaceSlackBot> <pbecker> for DataCite we have a table as @bollini already pointed out.
[15:27] <DSpaceSlackBot> <mwood> Yes. I always worry about that word "should" when talking about automatic processes.
[15:27] <DSpaceSlackBot> <mwood> The DataCite code already uses a field that is *not* used by the submission UI, so those DOIs should pose no problem.
[15:28] <DSpaceSlackBot> <bollini> yes, if the prefix match it is a doi generated by dspace or at least a doi that now is under the dspace responsability
[15:28] <DSpaceSlackBot> <tdonohue> So, how about if we turn this into a proposal to simply run past DCAT (i.e. could be documented in a JIRA ticket)? We propose to automatically move all DOIs generated by DSpace into `dc.identifier.doi` in DSpace 7.0. This will standardize where DOIs are found on DSpace objects, and should not affect DOIs you add manually to any other fields.
[15:28] <DSpaceSlackBot> <tdonohue> And then see how they respond
[15:28] <DSpaceSlackBot> <mwood> There is already some migration code in a PR somewhere, to move the EZID-generated DOIs using pattern matching similar to what we are discussing.
[15:29] <DSpaceSlackBot> <mwood> What about Handles? dc.identifier.handle?
[15:30] <DSpaceSlackBot> <pbecker> @mwood good questions. That would make sense to me.
[15:30] <DSpaceSlackBot> <tdonohue> @mwood: I'd treat that as a separate question. Not sure how far we want to unravel this
[15:30] <DSpaceSlackBot> <pbecker> But if someone is not using CNRI handles?
[15:30] <DSpaceSlackBot> <pbecker> With handles you can always change the handle resolver to dspace.url/handle and use not official handles...
[15:31] <DSpaceSlackBot> <mwood> Currently it is not possible, not to use Handles. At least one must accept the 1234566789 prefix. DSpace code assumes that Handles are present.
[15:31] <DSpaceSlackBot> <tdonohue> While I'm not against moving other identifier values around, I refrain from doing so with a real goal/purpose in mind. We have a purpose for DOIs (they are stored in multiple places, and it's confusing). Less clear why we'd want to move Handles immediately
[15:32] <DSpaceSlackBot> <tdonohue> (The only argument that comes to mind is "consistency with DOIs", but that's not a very good argument in my opinion)
[15:32] <DSpaceSlackBot> <mwood> Mainly just to keep all generated Identifiers together.
[15:33] <DSpaceSlackBot> <tdonohue> My concern is that we have this DSpace Entities WG starting up that may start proposing Data Model changes. If Data Model changes turn into metadata-ish changes, we may want to wait to see what comes out of those discussions....before just moving metadata around just for "consistency"
[15:33] <DSpaceSlackBot> <pbecker> @mwood: I a handle with a prefix of 123456789 is not a handle. ;)
[15:34] <DSpaceSlackBot> <mwood> Eh, it is a Handle in the same way that 192.168.1.1 is an IP address.
[15:34] <DSpaceSlackBot> <pbecker> I would prefer to have separate fields for DOIs and handles. I would like to know "the value in this field is a DOI for sure".
[15:35] <DSpaceSlackBot> <pbecker> So lets start with DOI and then we can proceed if necessary?
[15:35] <DSpaceSlackBot> <tdonohue> I fully agree with what I believe is @mwood's overarching point...that our Metadata is not very consistent / is a bit messy right now. But, I'd rather we discuss that at a higher level first, to determine future strategies to fix that.
[15:35] <DSpaceSlackBot> <mwood> If we are going to put them in dc.identifier.whatever then Handles can remain in dc.identifier.uri for now. I have been thinking that, since DCMI doesn't define *any* of these fields that we are discussing, identifiers would move to some other namespace (dspace.identifier.* perhaps.) I need to let that idea go.
[15:36] <DSpaceSlackBot> <pbecker> I won't be able to write the ticket at least before next week. I know it doesn't take long, but I'm still cleaning up after the migration from Monday.
[15:36] <DSpaceSlackBot> <tdonohue> For now, I agree with @pbecker... let's start with DOI. Table other discussions for later. I think metadata cleanup may need a working group (and I'm not sure if the Entities WG will discuss it at all, or leave it for another WG)
[15:36] <DSpaceSlackBot> <mwood> Agreed.
[15:37] <DSpaceSlackBot> <terrywbrady> The next DCAT meeting is 10/10. I recommend that you get on the agenda ASAP if you need input from the group
[15:38] <DSpaceSlackBot> <pbecker> then someone else will have to write it or we aim the next meeting. It was hard for me to free time for this meeting already.
[15:38] <DSpaceSlackBot> <tdonohue> Do we have a JIRA ticket for this? I suggest summarizing in a JIRA ticket the proposed changes. Then getting them on DCAT agenda (ideally for next week, if possible, since they only meeting once per month)
[15:38] <DSpaceSlackBot> <mwood> I can write a ticket.
[15:38] <DSpaceSlackBot> <tdonohue> Thanks @mwood!
[15:39] <DSpaceSlackBot> <tdonohue> @terrywbrady could you get this on the DCAT agenda? Or would you rather someone else forward this along to Maureen?
[15:39] <DSpaceSlackBot> <pbecker> DS-3472
[15:39] <kompewter> [ https://jira.duraspace.org/browse/DS-3472 ] - [DS-3472] Metadata recommendations on Publisher DOI vs Repo generated DOI - DuraSpace JIRA
[15:40] <DSpaceSlackBot> <terrywbrady> I would rather have someone else raise it. I do not deal with DOI's so I would not be able to represent the conversation.
[15:40] <DSpaceSlackBot> <pbecker> DS-2199 is relevant too.
[15:40] <kompewter> [ https://jira.duraspace.org/browse/DS-2199 ] - [DS-2199] DSpace stores DOIs in different metadata values depending on which DOI registration agency is used - DuraSpace JIRA
[15:40] <DSpaceSlackBot> <tdonohue> I'd recommend we may want to create a new ticket for this proposal...and link it up to 3472 and 2199. Both those other tickets have good info here, but they are messy tickets
[15:41] <DSpaceSlackBot> <pbecker> thank you!
[15:42] <DSpaceSlackBot> <pbecker> We have 19 minutes left. May I bring up some more topics?
[15:42] <DSpaceSlackBot> <tdonohue> Ok. If we get this ticket created, I'll forward it along to Maureen...and see if I can attend next week's DCAT meeting
[15:42] <DSpaceSlackBot> <tdonohue> Yes, we can move along to other topics for today
[15:42] <DSpaceSlackBot> <pbecker> I think we should discuss DSpace 6.3.
[15:43] <DSpaceSlackBot> <pbecker> I think after fixing DS-3627 we should release 6.3 sooner than later.
[15:43] <kompewter> [ https://jira.duraspace.org/browse/DS-3627 ] - [DS-3627] Cleanup utility leaves files in assetstore - DuraSpace JIRA
[15:44] <DSpaceSlackBot> <pbecker> I would love to see DSPR#1848, DSPR#1845 (or something else that solves the issue behind) and DSPR#1835 going into 6.3 as well.
[15:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1848 ] - DS-3700: MediaFilterServiceImpl forgot to close an input stream. by pnbecker ¡ Pull Request #1848 ¡ DSpace/DSpace ¡ GitHub
[15:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1845 ] - [DS-3662] DSpace 'logging in' without password or with non-existent e-mail using Shib and Password authentication by jrihak
[15:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1835 ] - DS-3681: Refactoring of DSpaceAuthorityIndexer by AlexanderS
[15:46] <DSpaceSlackBot> <tdonohue> I agree with that. I'm fine with a 6.3 release sooner rather than later. I think we mainly need someone to coordinate the release, etc. (I have to admit my time is split more and more these days)
[15:47] <DSpaceSlackBot> <pbecker> I probably could do a release by the end of October.
[15:47] <DSpaceSlackBot> <tdonohue> And creating a wiki page of tickets/PRs to review/test would be a good first step here. Those linked above look reasonable to me, just need volunteers to help test (most have had some code review already)
[15:48] <DSpaceSlackBot> <pbecker> But before end of October I'm quite busy, so I'm probably not the one orchestrating the reviews.
[15:49] <DSpaceSlackBot> <tdonohue> We might be able to find reviewers for PRs in these meetings, provided a list.... Maybe we start this by simply creating a new 6.3 Release Status wiki page, gathering PRs of interest, and then I can help push for reviewers/testers in this meeting for specific PRs?
[15:50] <DSpaceSlackBot> <pbecker> sounds great.
[15:50] <DSpaceSlackBot> <pbecker> I will look for such a wiki page next week and create one if no one else was faster.
[15:50] <DSpaceSlackBot> <tdonohue> There are also a good number of "quick win" PRs still open that might fit in here...but again, we'd need help testing them out (from anyone, even just interested developers who want to chip in here)
[15:51] <DSpaceSlackBot> <tdonohue> https://github.com/DSpace/DSpace/pulls?q=is%3Apr+is%3Aopen+label%3A%22quick+win%22
[15:51] <DSpaceSlackBot> <pbecker> (Sorry for not just volunteering, but I don't want to give promises I cannot hold)
[15:51] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Apr+is%3Aopen+label%3A%22quick+win%22
[15:51] <DSpaceSlackBot> <pbecker> @tdonohue I would leave this for now and open up one last other topic if I may.
[15:52] <DSpaceSlackBot> <tdonohue> That's fine. We can just ensure a 6.3 wiki page is created in the next week. In the meantime, others can feel free to start scheduling PRs of interest for (possible) 6.3 inclusion
[15:53] <DSpaceSlackBot> <pbecker> I would like to talk for a moment how we can prevent bugs like 3627 in future versions. It was a small simple bug, that could happen to all of us but one that might have bin spotted during a review. I personally think we need a way to review even huge PRs like the service API one. To finish the support for the service API we shared the work. Maybe we can add a rule to limit the size of a single commit in a PR
[15:53] <DSpaceSlackBot> huge PRs?
[15:54] <DSpaceSlackBot> <mwood> The Linux kernel is like that. Linus just won't accept huge monolithic patches.
[15:55] <DSpaceSlackBot> <tdonohue> I'm not against the idea, but I also think part of the problem is a lack of Unit Tests (in many areas of the code). We also could consider *requiring* unit tests.
[15:55] <DSpaceSlackBot> <tdonohue> Is it possible to limit the size of PR commits via GitHub itself? Or would this be a lot of manual work to ensure we are all following this rule?
[15:56] <DSpaceSlackBot> <mwood> I don't think I could propose a good mechanical test. It's as much a matter of complexity as of size.
[15:56] <DSpaceSlackBot> <pbecker> github shows on every patch how many files were touched, how many lines added and how many lines removed.
[15:57] <DSpaceSlackBot> <pbecker> But maybe we do not need a hard rule.
[15:57] <DSpaceSlackBot> <pbecker> Maybe it is enough to say in our code contribution guidelines "commits that can be handled enduring a proper review".
[15:57] <DSpaceSlackBot> <mwood> But we *do* need to offer some guidance as to what would make us say "break that down in pieces and try again."
[15:58] <DSpaceSlackBot> <terrywbrady> I think we need to be careful about creating rules/practices that could become a barrier to new committers.
[15:58] <DSpaceSlackBot> <tdonohue> I'll also note that we've started *requiring* unit test coverage *increases* (or at least doesn't get worse) in PRs for `dspace-angular` (i.e the PR fails the build if coverage goes down). Take a look at https://github.com/DSpace/dspace-angular/blob/master/README.md (you'll see we currently don't have great test coverage, yet, but we're working on it)
[15:58] <kompewter> [ dspace-angular/README.md at master · DSpace/dspace-angular · GitHub ] - https://github.com/DSpace/dspace-angular/blob/master/README.md
[15:58] <DSpaceSlackBot> <mwood> The more we can say about what is problematic, the more likely it is that we won't have to reject a patch simply because it is too hard to review.
[15:59] <DSpaceSlackBot> <tdonohue> We could start to do something similar on "master", tracking test coverage, flagging PRs that decrease is as "failed" (that way we are notified there's an issue, and can choose to override it, or tell the developer to add tests)
[15:59] <DSpaceSlackBot> <mwood> IOW tell contributors in advance how to build a successful PR.
[15:59] <DSpaceSlackBot> <pbecker> Every developer how is able to do a 100k PR should not that this is unreviewable. And he/she should be experienced enough to have a feeling what can be reviewed and how it could be splitted in tasks.
[16:01] <DSpaceSlackBot> <pbecker> Asking for unit tests is a bigger hurdle than asking for more, smaller commits in a PR.
[16:01] <DSpaceSlackBot> <tdonohue> I do agree with @terrywbrady too... but, I think if we are clear about PR requirements, we can make them a bit more strict. I'd just rather see us find a way to automate "rules" (which provides immediate feedback to developer) instead of relying on manual approvals (which is sometimes much less immediate)
[16:01] <DSpaceSlackBot> <pbecker> We have the rule I want: everything must be reviewed. But we ignored it, as it came from a trusted developer and was "to huge".
[16:02] <DSpaceSlackBot> <terrywbrady> I was tempted to quit offering contributions to the project after being asked to rewrite my commit history multiple times.
[16:02] <DSpaceSlackBot> <pbecker> Maybe we do not even need any new rule, but have to follow the existing ones more strictly?
[16:03] <DSpaceSlackBot> <tdonohue> @pbecker: we didn't really "ignore it". But, we made an exception for that entry...and told ourselves that testing it out (in testathon) should find all the major bugs. It found most/many, but obviously not all of them
[16:04] <DSpaceSlackBot> <pbecker> We were lucky that DS-3627 was not much bader, as another bug in DSpace 6 prevented us from deleting many files we should have kept.
[16:04] <kompewter> [ https://jira.duraspace.org/browse/DS-3627 ] - [DS-3627] Cleanup utility leaves files in assetstore - DuraSpace JIRA
[16:04] <DSpaceSlackBot> <tdonohue> I think this has been a good discussion. I'm not sure we have a decision here, but at least things to think about.
[16:04] <DSpaceSlackBot> <pbecker> I think DS-3627 is a hint to rethink if we would do such an exception again.
[16:04] <kompewter> [ https://jira.duraspace.org/browse/DS-3627 ] - [DS-3627] Cleanup utility leaves files in assetstore - DuraSpace JIRA
[16:05] <DSpaceSlackBot> <mwood> We let the release schedule drive our decision. Perhaps we should have said, "okay, we'll slip the schedule enough to figure this out, or let it wait."
[16:05] <DSpaceSlackBot> <tdonohue> I also do believe we've "learned" from past mistakes a bit in the DSpace 7 efforts. We are requiring UI-level tests for that effort
[16:06] <DSpaceSlackBot> <tdonohue> We are not yet requiring unit tests on `master` (for DSpace 7 API / REST), but we could consider that as well
[16:07] <DSpaceSlackBot> <pbecker> So, I may bring it up, if we ever will discuss such an exception again. ;)
[16:07] <DSpaceSlackBot> <mwood> A test for 3627 would really be an IT, since it involves going all the way down to the filesystem.
[16:07] <DSpaceSlackBot> <pbecker> sorry, for prolonging the meeting, thank you all for your time, ideas and the discussion!
[16:08] <DSpaceSlackBot> <mwood> Thank you @pbecker for starting the discussion.
[16:08] <DSpaceSlackBot> <terrywbrady> I am still quite discouraged by the lack of response to my requests to DCAT for testing of the following release.
[16:09] <DSpaceSlackBot> <tdonohue> Thanks as well. I think it's a good discussion. I would be interested in talking more about how to treat PRs to `master` going forward (in future meetings). As I think we might be OK with making that much more "strict" considering I expect more PRs to end up being UI-based in future.
[16:09] <DSpaceSlackBot> <mwood> @terrywbrady then we need to start writing end-to-end tests.
[16:10] <DSpaceSlackBot> <tdonohue> But, we'll leave it there for today. Let's close out the official meeting. If folks still want to chat, you are welcome to stick around and do so. But, no new topics will be raised
[16:11] <DSpaceSlackBot> <tdonohue> Thanks all!
[16:51] <DSpaceSlackBot> <bollini> as some of you know I'm at a conference in these days so I left the dev meeting in the meeting. It was a very good conversation. I share the feel of many here about the mistake made in version 6 about easy acceptance / lack of testing. It is not easy as often we have contributor that generously share their code but don't have extra time to provide additional test (automatic or not) and other developers jump o
[16:51] <DSpaceSlackBot> issue... we need to balance rules and openess this is for sure a conversation to keep on
[16:57] <DSpaceSlackBot> <bollini> in relation to the above :point_up: please keep in mind that we need help to setup the test framework for the new REST API, see https://jira.duraspace.org/browse/DS-3484
[16:57] <kompewter> [ https://jira.duraspace.org/browse/DS-3484 ] - [DS-3484] Setup a test and documentation framework for the REST API - DuraSpace JIRA
[16:57] <kompewter> [ [DS-3484] Setup a test and documentation framework for the REST API - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3484
[17:00] <DSpaceSlackBot> <mwood> One thing that would help: the larger the work, the sooner it should be seen by others.
[17:02] <DSpaceSlackBot> <bollini> and we have the *work in progress* label to flag the PR appropriately
[17:12] <DSpaceSlackBot> <mwood> DS-3708
[17:12] <kompewter> [ https://jira.duraspace.org/browse/DS-3708 ] - [DS-3708] Isolate DSpace-generated DOIs from other identifiers - DuraSpace JIRA
[21:08] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:51] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.