2020-11-19 DSpace 7 Working Group Meeting

Date

19 Nov 2020 from 15:00-16:00 UTC

Location: https://lyrasis.zoom.us/my/dspace (Meeting ID: 502 527 3040).  Passcode: dspace

• More connection options available at DSpace Meeting Room

Agenda

• (BEFORE MEETING IN #dev-sprint) Developer Stand Up - Developers give brief updates on their effort (or their team's effort).

  • Update/see "Current Work" section below based on your status. Please feel free to update prior to meeting.
  • Please highlight any new work (needing reviews/testing), any blockers (for you), and any discussion topics you may have.
• (30 mins) General Discussion Topics
  1. (20 mins) Start discussion of "150 GET requests on Community & Collection page" (would require REST API changes): https://github.com/DSpace/dspace-angular/issues/918
     1. Feedback from Ben Bosmanon the feasibility of Art's idea to "add support for pagination options when requesting embeds: e.g. /api/core/communities/<:uuid>?embed=subcommunities&embed.subcommunities.size=1)"
  2. (10 mins) Start discussion about improving our JAVA test practice (note below from Andrea Bollini (4Science) )
     1. In recent PRs (see 3034 and 3046) it is becoming evident that there is some confusion between practices needed (and supported) in (REST) Integration Test  and practices applied to "old" test in dspace-api (both Unit than Integration)
     2. we should make sure that developers know about such pitfalls
        1. we have an AbstractUnitTest class in dspace-api that is not about Unit Testing as it setup a real database connection so it allows you to manipulate persistent data, moreover we inject real services in the base AbstractDSpaceTest. We also have an AbstractIntegrationTest that extends AbstractUnitTest with a not well defined purpose... and it is easly to be confused with AbstractDSpaceIntegrationTest that instead is the "new" base Integration Test class introduced in the REST layer and now move to the DSpace-API. It should be noted that AbstractDSpaceIntegrationTest is not in hierarchy with the AbstractDSpaceTest and following old dspace-api classes. This last class is the only one that make an effort to automatically cleanup the persistent data after each test execution and restore a clean context
        2. the name of the Test Class is relevant as we follow the standard naming convention used by maven to identify Unit Test (the class that starts or ends with Test) and Integration Test (the class that starts or ends with IT). Recently we have split our CI build in two parallel processes one dedicated to Unit Test and one dedicated to Integration Test, so depending on the name the test now end in one process or the other (but as said in the previous point we currently have almost only IT)
        3. old Integration Tests named as such in the dspace-api could fails to cleanup the test env and this could result in subsequent failure in other test very hard to identify (I'm currently surprised that we haven't hit such problem yet and frequently, probably they are few and touch a little amount of data or they do a good job to manually cleanup what they touch)
     3. do we need real Unit Test? maybe, personally I feel more comfortable with IT, unit test could be useful where we have complex logic that we want to stress but when we need to deal with Services probably it is more useful to use IT (otherwise we will end in writing Unit Test more complex than the actual code due to the need to mock a lot of collaborators)
     4. how to proceed in the long run? if we call the test properly we will get a lot of issues due to the failing cleanup and we will lose the gain due to the two build processes (as essentially we have no or few real unit test). It is possible to classify test and use such classification to trigger the execution of only a group of them, this could be an alternative to the current split (unit test vs IT) see https://github.com/junit-team/junit4/wiki/Categories
  3. (Other discussion topics welcome)
• (30 mins) Planning for next week
  
  • Topic of Discussion for Nov 26: "Entity type/label as part of URL path" (requested by Google Scholar): https://github.com/DSpace/dspace-angular/issues/745
  • Review of our Beta 5 Project Board & assigning PRs to reviewers.
  • Beginning to assign work

Attendees

• Art Lowel (Atmire) 

• Andrea Bollini (4Science)

• Tim Donohue

• Lieven Droogmans

• Giuseppe Digilio (4Science)
• Ben Bosman
• Paulo Graça

7.0 Release Goals

These resources define the prioritization and general schedule we are working towards

• DSpace 7 Release Goals : overview of goals/timelines & beta release process
• DSpace 7 Project Boards : our planning/scheduled boards which details which features are scheduled for each Beta release.

Current Work

Project Board

DSpace 7.0 Beta 5 Project Board: https://github.com/orgs/DSpace/projects/4

To quickly find PRs assigned to you for review, visit https://github.com/pulls/review-requested  (This is also available in the GitHub header under "Pull Requests → Review Requests"

Security / Performance Tests

Brainstorming options for security testing & performance testing.  How do we want to handle both of these prior to 7.0 final?

1. Security Review/Scanning of pre-7.0:  See DSpace 7 Security Analysis 
2. Performance testing of pre-7.0: See DSpace 7 Performance Analysis

Delayed / Needs Discussion

1. Finalize / approve the initial list of all authorization features which we should implement for the /api/authz/features REST endpoint.  This list of features should be limited to only features which are required to enable/disable User Interface functionality. (In other words, we can always add more features in the future.  We just need to approve the list necessary for 7.0)
   1. 1. Review current spreadsheet (from Andrea Bollini (4Science) ) : https://docs.google.com/spreadsheets/d/1182LcD_WqIZRbUGWpLtBw0aOMR9jhbOVB7GZqtTpR9A/edit?usp=sharing 
         1. Art Lowel (Atmire) : I don't see any immediate issues with the current set of features, but I would prefer a consistent naming scheme. I'd use canDoSomething for everything
         2. Tim Donohue added possible renames of these features based on Art's idea (see cell comments in spreadsheet).  I like the "can[DoSomething]" naming scheme as well.
2. (REST Contract) Edit Homepage News: https://github.com/DSpace/Rest7Contract/pull/45
   
   1. Delayed. General agreement (in meeting on March 21, 2019) that storing HTML in metadata fields is not really ideal behavior.  Metadata (from a librarian standpoint) tends to be free of format-related markup (as that allows for easier sharing, understanding of metadata.  Currently Community & Collection homepage information is HTML-based and is stored in metadata that is appropriate for a minor subset of information (like the title) but it is better to move large/rich text to bitstreams.  
   2. Proposal here is to consider storing HTML-based markup (for Site, Community & Collection homepages) in Bitstream(s) associated with the object in question.  May allow for more CMS-lite behavior in the future
   3. Timeline for this is uncertain.  Possibly in 7 or 8. May depend on how/whether it can be scoped.

Notes