Versions Compared

Key

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

...

  • (30 mins) General Discussion Topics
    1. Planning for 7.6
      1. Review the 7.6 board
        1. Steering has voted to fund the following tasks for 7.6.  Need volunteers to claim.
          1. Upgrade to Angular 15 (estimated at 60hrs): https://github.com/DSpace/dspace-angular/issues/2043
          2. Support "Primary Bitstream" concept (estimated at 40-60hrs): https://github.com/DSpace/DSpace/issues/3349 and https://github.com/DSpace/dspace-angular/issues/1578
          Determine which tickets need to be brought back to Steering for possible funding (see "needs funding" label)
        2. Determine which tickets in "In Progress" column are still being worked on for 7.6.  Do any of these need to be taken off the 7.6 board and moved to 8.0?
        3. 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
          2. Administer Workflow Actions no longer work: https://github.com/DSpace/dspace-angular/issues/2118
      2. Finalize Timeline for 7.6:  Looking at an early June release (possibly announce on Monday, June 5?), unless we feel it can be moved forward into May.
        1. Tim will update release schedule above once we set a goal.
      3. General rule for 7.6:  New features are welcome if they used to exist in 6.x.  Everything else must be a fix that would normally be acceptable in a "bug fix only" release.
        1. 7.6 is a "transition" release, where we are transitioning back to our release numbering scheme
      4. 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. With 8.0 however, we would move back to our existing release numbering scheme.  Bug fix releases would be numbered 8.1, 8.2, 8.3, etc.
    2. (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 
    3. (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 likely 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.
    4. (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

...