Versions Compared

Old Version 2

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 3

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • (30 mins) General Discussion Topics
    1. Planning for 7.6
      1. Finalize Timeline for 7.6: Proposed timeline is above. Are we satisfied with it?
      2. Very High priority bugs located in 7.5:
        1. Submission form "Type" dropdown changes values when pressing Enter: https://github.com/DSpace/dspace-angular/issues/2145  Might be related to Safari browser dropdown issues: https://github.com/DSpace/dspace-angular/issues/2124
      3. Releases after 7.6:  Later releases will be bug-fix only.
        1. Andrea Bollini (4Science) and Lieven Droogmans suggest to switch to a 7.6.1, 7.6.2, 7.6.3 for eventual bug fix release. This clarifies that 7.6 is the final feature release, and that every later release is a minor upgrade.
    2. Updates on Advanced Search Filter Development (DSquare Technologies)
      1. Demonstration of work done on https://github.com/DSpace/DSpace/issues/8431 & gathering feedback.
    3. (NO UPDATES) Demo Site maintenance (https://demo7.dspace.org/ and https://api7.dspace.org/server/)?  
      1. LYRASIS is still working on this, but some restructuring of plans has had to occur because of internal deadline changes.  Likely not to be completed until late March or April.
      2. In the meantime, can we ensure that it is still possible to send updates to both the frontend & backend per instructions at Updating DSpace 7 Demo Sites 
    4. (Future Topic) Lyrasis' new CEO has asked Tim Donohue to investigate what it would take to implement OCFL-based storage (or similar preservation-friendly storage) for DSpace (v8 or later)
      1. Early brainstorm is to keep DSpace's existing database & Solr usage as-is.
      2. However, migrate from current "[dspace]/assetstore" to an OCFL storage structure. 
        1. OCFL storage would contain both the content file(s) (PDF, etc) and a metadata representation (exported/synced from database). The metadata representation might be similar to our existing DSpace AIP Format.
        2. Tools would need to verify/validate that data in OCFL storage "matches" with what is in the database (similar to a Checksum Checker, but more specific to OCFL storage)
      3. If anyone is interested in brainstorming this idea further, get in touch with Tim.
    5. (Other topics?)
  • (30 mins) Planning for next week
    • Review the Backlog Board - Are there any tickets here stuck in the "Triage" column?  We'd like to keep this column as small as possible.
    • Review the 7.6 Project Board - Assign tickets to developers & assign PRs to reviewers.
      • Paid (by DSpace project) developers must keep in mind priority. If new "high" or "medium" priority tickets come in, developers should move effort off of "low" priority tasks.
      • Volunteer developers are allowed to work on tickets regardless of priority, but ideally will review code in priority order

...