Versions Compared

Key

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

...

  1. Announcements
    1. New lyrasis CEO started today
    2. Cleaning up registry of institutions that use fedora, reaching out to organizations
  2. Pop-up/Other Topics:
    1. TACC Use Case
      1. Using Fedora 5 as metadata/structure store only, since data itself is too large (simulations, field experiments)
      2. All the info stored in Fedora is in a manifest file. Too To be a trusted digital repo, they have file info produced outside of fedora which they store in the manifest, but want to store in Fedora.
      3. Want checksum and file format identification in PREMIS in fedora
      4. Hierarchy of nested containers make up experiments, difficult to pull, many member problems in Fedora 5 if each binary represented as a resource
      5. They will get back to us with examples of their data and desired structure so that we can provide better feedback. They will also make an effort to move to Fedora 6, which could help with many members problem.
    2. Fcrepo LTS Version
      1. Update page to say what version is the LTS
      2. Going to bring recommendation to leadership group about which group should be the LTS (probably suggesting 6)
    3. Java Version updates
      1. Support the version of java that was used for the LTS version of fedora
      2. Java 11 will be support until at least 2026, but we can try running our build against java 17 as well.
      3. Peter previously worked on updating dependencies to work with java 17 https://github.com/fcrepo/fcrepo/pull/1937
      4. We will create a ticket to try java 17 in the docker container (with current tomcat), and a ticket to add 17 to the github test matrix
  3. Testing: Release Testing - 6.3.0
    1. Needs more testing, mark the matrix with the results
  4. Migration Updates:
  5. Updates on:

  6. New tickets:
    1. Fcrepo-3866
      1. Need to look at this before the release of 6.3.0 to see if it impacts anything
    2. Fcrepo-3865
      1. Running reindex without having to set a startup flag, which can result in accidental reindexes which can be very expensive
      2. Would be nice to be able to reindex while server is up, maybe via command line or http endpoint
      3. Or skip truncating tables and reindex over existing data
      4. During reindexing, we currently disallow access to API. We would at least want Fedora to be read only during the live reindexing