Developers Meeting on Thurs, July 20, 2023

Time/Location

20 Jul 2023 from 14:00-15:00 UTC

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

• More connection options available at DSpace Meeting Room

Agenda

• Discussion Topics - If you have a topic you'd like to have added to the agenda, please just add it. 
  1. (30 mins) Angular : library-based architecture proposal updated proposal
     1. See also https://github.com/DSpace/dspace-angular/issues/2370 (Migrate to Standalone Angular Components)
  2. (30 mins) DSpace Preservation-enabled Storage via OCFL (proposal from Lyrasis for post-8.0). 
  3. 7.6.x release topics - bug-fixes only.   
     
     1. Any topics to discuss?
  4. 8.0 release topics
     1. Begin enforcing style in JSON5 (i18n) files: https://github.com/DSpace/dspace-angular/pull/2317
        1. We should have a strict style enforced here, so that our tooling and tests behave the same as our other code
        2. Reduces arbitrary errors caused by pull requests and will help users who perform local modifications to these files (merging custom i18n strings in a local fork is messy due to wild changes in whitespace, commas, and quoting)
  5. Demo Site migration to Lyrasis (https://demo7.dspace.org/ and https://api7.dspace.org/server/)  
     1. Tim will work with Lyrasis to make this happen as soon as reasonably possible now that 7.6 is released.
     2. Demo site will be renamed back to "demo.dspace.org" (instead of "demo7.dspace.org").   demo7.dspace.org and api7.dspace.org will redirect to demo.dspace.org
     3. Old 6.x demo site:  Will keep it around temporarily at "demo6.dspace.org"... likely only for 6-12 months though.
  6. (Other topics?)
• Board Review & assignments:
  • Backlog Board - Are there any tickets here stuck in the "Triage" column?  We'd like to keep this column as small as possible.
  • 7.6.1 Project Board - Assign new PRs to volunteers to code review and/or test.
  • 8.0 Project Board - Assign new PRs to volunteers to code review and/or test.

Attendees

• Tim Donohue 

• Art Lowel (Atmire) 

• Andrea Bollini (4Science)

• Paulo Graça
• Mark H. Wood 
• Grazia Quercia (4Science)
• Corrado Lombardi (4Science) 
• Julian Timal (eScire) 
• Martin Walk 
• Melissa Anez 

Upcoming Topics

If you have a topic for a future meeting, please add it here.

• 4Science proposed to present
  
  1. ORCID Login improvement on Auguest 2023 (exact date is to be determined)

Current Work

Project Boards

• DSpace 7.6.1 board: https://github.com/orgs/DSpace/projects/29
• DSpace 8.0 board: https://github.com/orgs/DSpace/projects/27

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")

Goals for 8.0

This were decided by Steering in their meeting on June 28, 2023.

1. Move forward major features which missed 7.x. 
   1. COAR Notify support (4Science & Harvard): https://github.com/DSpace/DSpace/issues/8120 
      1. Development proposal page: Implementation of the COAR Notify protocol in DSpace 8
   2. OpenAIRE integration with notification broker/claim service (4Science)
   3. Porting "REST-Based Quality Control Reports" from old REST API to new one. (U of Laval, Canada)
   4. Duplicate Detection in Submission ported from DSpace-CRIS (The Library Code)
2. Include new features which empower users in the admin UI.  Make things easier for Admins.
3. Improve documentation, training to allow for greater community contributions.  (Ease setup/install/customization, etc.)
   1. Per DSpace 7 WG meeting on June 29, 2023, this may include dependency upgrades/maintenance (Angular, Spring, Solr, Tomcat, etc).  May also include necessary code updates/refactors to ease in ongoing maintenance. 
4. Release Goal: April 2023
5. In parallel to 8.0, proof of concepts / planning regarding modularization (e.g. 4Science angular proposal) and OCFL/preservation storage (Lyrasis proposal to be discussed in more detail).

Goals for 7.6.1

• Bug/security fixes only.  Release will occur when sufficient fixes have been made to warrant a release.
• Fixes should have two Pull Requests (exceptions may be made for very small fixes)
  1. A PR against the "dspace-7_x" maintenance branch to apply to the next 7.6.x release.
  2. A PR against the "main" branch to fix this same bug for the 8.0 release.
  3. (NOTE: Once one PR is reviewed & approved, the other will be merged at the same time.)

Notes

• (50mins) Discussed updated proposal for Angular : library-based architecture proposal  (the new updates are in the section titled "POC Analysis Overview" midway down that page)
  • A new proof of concept branch has been created by 4Science at https://github.com/4Science/dspace-angular/tree/f/ej/nx-poc
    • This branch includes an initial migration to "Standalone components" (as described in the wiki page above and in https://github.com/DSpace/dspace-angular/issues/2370)
    • This branch also includes an initial migration to using NX with a library-based approach.  A few example libraries are in this folder: https://github.com/4Science/dspace-angular/tree/f/ej/nx-poc/libs
  • Discussion of benefits of the Standalone components and NX itself.  See wiki page for that list.
  • Feedback:
    • General interest from others
    • Need to analyze the risks (short term and long term) of these approaches.  A lot of benefits are listed, but it's unclear if there are any risks.
      • This may have more to do with library-based approach / NX. 
      • The "Standalone Components" idea is now the "best practice" way of doing things in Angular: https://angular.io/guide/standalone-components (There's a video on this page which describes benefits).  It can be used regardless of whether we switch to NX or not.
  • Next Steps:
    • All Developers are encouraged to try out the 4Science branch at https://github.com/4Science/dspace-angular/tree/f/ej/nx-poc.  Feedback can be added to the wiki page at Angular : library-based architecture proposal
    • Tim recommends 4Science may want to create an initial PR which is just  the migration to "Standalone Components".  This might be a good first step, as it doesn't require NX and seems like a possible "quick win".
    • We will revisit this topic in future meetings.  Because of upcoming vacations from key team members, it may not receive detailed discussion until later this Summer.  However, Tim will keep this on the agenda in case questions/comments come up in the next few weeks.
• (10mins) Very brief overview of DSpace Preservation-enabled Storage via OCFL
  • Tim noted this came from recommendations from new Lyrasis CEO.  Project would be funded by / built by Lyrasis, but collaborations would be welcome.
  • General goal is to find a way to implement "object-based" storage in DSpace.  Tim tried to brainstorm a way to do with with the least amount of impact on how DSpace currently works.  Approach detailed in the document is just to replace the "assetstore" (which just stores bitstreams) with an object-based storage (which stores bitstreams and exported metadata).  Currently the recommendation is to look at OCFL, since that aligns well with this object-based storage approach.  But, other ideas are also welcome.
  • Initial document is really a rough brainstorm.  No prototyping or proof of concepts have been built yet.  No work has been done on this at all. We are just in a feedback gathering state.
  • Feedback can be added directly into that Google Doc.  Feel free to add comments inline, or add feedback at the very bottom (in the section for feedback).  Anyone can add feedback and you can add it anonymously if you wish.
  • Quick feedback in meeting:
    • General support for the concept of object-based storage in DSpace.  Others have heard this same need.
    • Concerns expressed over how to make this work without performance issues.   For example, we would not want to write every metadata change to this "preservation-storage" immediately after the change occurred...that could result in a lot of file writing which could bog down the system. But, also don't want the preservation-storage to not be very outdated.  May require a proof of concept.
  • Next Steps:
    • Tim asks for additional feedback in google document (DSpace Preservation-enabled Storage via OCFL) itself.  We'll bring this to another meeting for more discussion in the future.  May not be until Aug though because of many vacations coming up.