Developers Meeting on Thurs, July 6, 2023

Time/Location

06 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

• (40 mins) Discussion Topics - If you have a topic you'd like to have added to the agenda, please just add it. 
  1. 7.6.x release topics - bug-fixes only.   
     
     1. Development process reminder
        1. Two development branches: dspace-7_x and main  & new "port to 7.x" and "port to main" labels
        2. Two project boards in GitHub: DSpace 7.6.x Maintenance and DSpace 8.0 Release
  2. 8.0 release topics
     1. Anything new to discuss?
  3. Stale issues/PRs in GitHub 
     1. v6.x is now EOL. Tim will be closing all old issues/PRs related to 6.x (and 5.x if any still open).  These are all obsolete.
     2. Should we consider enabling Github's "stale" action, which will auto-warn if a PR/issue is "stale" and then auto-close it if no further activity occurs?
        1. E.g. We could flag s as "stale" after 1-2 years.  Then automatically "close" if no more activity for an additional 2 weeks to 1 month?
        2. PRs - Flag as "stale" for 2 years.  Close after 1 month.
        3. Issues - Flag as "stale" after 1 year.  Configure message to ask to reproduce again.  Close after 2 months.
  4. 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"). 
     3. Old 6.x demo site:  Should we keep it around temporarily at "demo6.dspace.org"?  Or just shut it down?
  5. (Other topics?)
• (20 mins) 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 
• 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. COAR Notify on July 13th 2023
  2. ORCID Login improvement on July 20th 2023
  3. Angular : library-based architecture proposal updated proposal on July 20th

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)
   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 MUST be applied to the "dspace-7_x" maintenance branch (for either backend or frontend)
• Fixes MUST be either cherry-picked to "main" branch (for 8.0) or copied into a PR against "main".

Notes

• Stale issues/PRs in GitHub
  • v6.x is now EOL. Tim will be closing all old issues/PRs related to 6.x (and 5.x if any still open).  These are all obsolete.
  • Regarding the GitHub "stale" action.
    • Lots of good discussion.  Concerns expressed about annoying developers.  While we want to remind  developers/ourselves when issues or PRs are "stale" or old, we want to avoid being annoying or closing anything without any explanation.
    • Decided to try two different rules for PRs vs Issues:
      • PRs - Flag as "stale" for 2 years.  Close after 1 month.  (Goal is to close PRs which are likely now obsolete – after two years, they've missed two releases.  Either update the PR or we close it)
      • Issues - Flag as "stale" after 1 year.  Configure message to ask to reproduce again.  Close after 2 months.  (Goal is to auto-revisit any Issue that has been overlooked for one year.  If it's a bug, ask if the developer can reproduce it on the latest version of DSpace.  Close if no response/updates)
      • We will configure nicer messages for the "stale" warning to make it clear we need to revisit this older work.
      • Tim will notify developers on Slack & dspace-devel before implementing this. The initial run of this action may catch a lot .  We don't want to annoy everyone, so we should pre-warn them.
• While visiting Boards, we revisited discussion of the 7.x maintenance.
  • How do we deal with bug fixes & applying them to both 7.x and 8.0
  • Do we require them all to be applied to a single branch (either dspace-7_x or main)?    Seems like that may be hard as it could require a developer wanting to submit a small fix to get familiar with unfamiliar code
  • Do we apply everything to "dspace-7_x" and then merge the "dspace-7_x" branch into "main" to sync up changes in bulk?  Concerns that waiting too long will let these branches diverge.  Fixes applied to 7.x may be needed on main.  We want these branches to hopefully be "in sync" at all times.
  • Can we require multiple PRs?  One against "dspace-7_x" and one against "main"
    • This is a lot of work for developers, but it may be necessary for larger fixes to ensure they can be easily applied to both changes.
    • Smaller fixes could be an exception  to the rule (similar to our "1 Approval" exception to 2-person code review rule for smaller PRs).  They can be applied to either branch & Tim will cherry-pick or create a small PR to fix on other branch.
    • Tim will add these notes to our "Goals for 7.6.1" section in next weeks agenda.  DONE: 2023-07-13 DSpace Developers Meeting#20230713DSpaceDevelopersMeeting-Goalsfor7.6.1