Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Developers Meeting on Thurs, July 18, 2024

Time/Location

 from 14:00-15:00 UTC

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

Agenda

Attendees

Current Work

Project Boards

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 9.0

To be decided by DSpace Steering Group with feedback from Leadership Group. 

Early brainstorms at DSpace Release 9.0 Status.  Please feel free to add your own brainstorms or link in tickets that you wish to be considered. 

Goals for 8.1 / 7.6.3

Deadline is TBD for both 8.1 and 7.6.3.  Bug fix releases do not have fixed/scheduled deadlines. Instead, the developer team will determine when to create a release based on the significance of the issues to solve. (e.g. If major issues are fixed, then a bug fix release will occur more rapidly.  If minor issues are found, then a bug fix release may be delayed until sufficient fixes have been made to warrant a release)

  • Bug/security fixes only.  These minor releases will not include any new features.
    • New "themeable components" (for dspace-angular) are allowed in bug fix releases, provided that they don't significantly modify component behavior or similar.
    • Accessibility fixes are also allowed in bug fix releases, provided they don't significantly modify component behavior or similar.
  • Bug fix PRs should be created against "main" branch where possible. The "main" branch has the most strict code style rules. (i.e. PRs created against dspace-7_x  are becoming more difficult to port forward.)
  • Per our support policy, bug fixes are only guaranteed to be ported back to 8.x.  That said, where possible, we'll try to backport bug fixes (especially significant ones) to 7.6.x.
    • Keep in mind, if a specific bug fix is important to you in 7.6.x, then it is best to create two PRs (one for main and one for "dspace-7_x").  If you are able to provide a backport version of the PR, then we will merge it alongside the "main" branch version.
    • NOTE: In many scenarios, a backport to "dspace-8_x" should be possible to automate using the "port to [branch]" labels & the "Port merged Pull Request" GitHub Action

Try "Pull Request Trading" for a quicker review

Do you have a PR stuck in "under review" that you really want to see move forward?  Or maybe it's someone else's PR but you want to get it more attention?

See Trading reviews on Pull Requests for how to get immediate attention to that PR!

Notes

Discussed version 9.0 planning and ideas

  • Ticket #3110 on GitHub (Server Side Rendering)
    • Hints/Notes section contains common threads of feedback regarding performance improvements
    • Others should add ideas/thoughts to this page if you've found ways to improve performance in production. 
  • Static Site Generation (SSG) in DSpace: https://github.com/DSpace/dspace-angular/issues/3183
    • Some discussion between Andrea & Pascal about Static Site Generation prioritization.
    • Andrea points out that we might want to avoid building too much into DSpace, but use external tools for caching and similar.  They've found benefits in having a prepopulated external cache for crawlers (and similar) to use.  This cache is based on the sitemap. The DSpace internal cache is not sufficient (others agree with this)
    • Pascal notes that the goal of SSG is along those lines.  Prepopulate static pages for crawlers.  Using the sitemap seems reasonable.
    • Others note that SSG needs to be done carefully. It will take a long time for every Item page to be statically generated (or cached) for large sites.   We all agree on this, the static generation would have to happen incrementally / behind the scenes (not all at once).  There'd also need to be a way for DSpace to know when to regenerate a specific page (e.g. an Event Consumer)
    • Overall goal here is not to require  SSG for all sites or all pages.  Any solution would need to be configurable.
  • Performance Improvements (General)
    • Andrea notes we need to look closer at making Item pages faster.  It takes too long to draw the Item page in general, which also has an impact on SSR (and caching or SSG).  Others agree.  Tim notes, if anyone can dig into slowness in the Item page, we should create a ticket around this (similar to other recent performance tickets about speeding up Submission or Search).
    • Tim invited committers to share their notes and thoughts on the Performance Tuning DSpace wiki page
  • Ongoing discussions (see agenda item #2): 
    • Tim encouraged committers & developers to contribute their thoughts to these, to suggest solutions, present ideas, research ways to address these issues
  • Reviewed "Under Discussion" section on 9.0 Status Page
    • Anyone can add topics to this 9.0 page that you'd wish to be considered for 9.0
    • A subgroup of Steering will be discussing and proposing priorities back to Steering / Leadership.  Developers have a chance to feed ideas into this group via this wiki page.





All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.