Time/Place
This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Audio/Video Conference Link: https://lyrasis.zoom.us/my/fedora
- Dial-in:
+1 408 638 0968
+1 646 876 9923
+1 669 900 6833
Meeting ID:
812 835 3771
- Dial-in:
Join fedora-project.slack.com on the "tech" channel
Attendees
Part 1:
- Danny Bernstein
- Peter Winckles
- Andrew Woods (out)
- David Wilcox
- Peter Eichman
- Joshua Westgard (out)
- Jared Whiklo
- Bethany Seeger
- Youn Noh
- Thomas Bernhart (might have to leave early)
- Ben Cail
- Rosie Le Faive
- Daniel Lamb
- Aaron Birkland
Part 2:
Agenda
- Announcements
- Sprint Planning
- 6.0 Architecture Review
- Coming to consensus on:
- Definition of "rebuild"
create all necessary indexes, caches, or other ancillary data structures derived from persisted content (OCFL + unversioned content)
- Definition of "rebuild"
- unversioned content
- What use cases must we support?
- Automatic versioning of staged content after X minutes/hours/days/weeks?
- Permanently unversioned content
- ?
- Issues to gain consensus on:
- Are we agreed that unversioned content will live outside OCFL Storage Root?
- ?
- What use cases must we support?
- Multi-object transaction implementation approach?
- Transaction Sidecar Spec Update
- Major Areas of Work
- Design/Development
- Interface Definition
- Persistence API
- ?
- OCFL Client Development
- OCFL Java API
- OCFL Java Client Implementation
- Transactions
- Interface Definition
- Documentation
- Testing
- Import/Export/Migration
- ?
- Design/Development
- Sprint Goals
- Status on organizing a Fedora documentation review
- Introduction to running Fedora with Valkyrie
- Applying a digital preservation framework (e.g. NDSA Levels of Digital Preservation) to Fedora 6
- Update on Fedora 6 Pilots
- Status
- API Test Suite PRs
- Minimal 4 →5 migration needs testing and code review:
- API Test Suite PRs
- Your topic here...
Tickets
In Review
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Notes
- Announcements:
- Good, well attended meeting in Switzerland. Interest in Fedora 6.
- Value prop of using Valkyrie with/without Fedora
- Fedora 4 & 5 about standardization
- Some performance issues
- Fedora 6 adding more preservation minded features
- Transparent, human-readable filesystem
- Rebuildability from FS
- Why better to use Fedora over Preservica?
- Preservica not active storage
- Fedora offers standard middleware integrations: notifications, robust api
- Fedora 4 & 5 about standardization
- Definition of Fedora rebuild
- Ability to recreate everything needed to run Fedora based on the files on disk (Daniel's exact words should be added here)
- Support unversioned content?
- Some use Fedora to author content over a period of time. They want to version when the content is ready and not have a version of every change.
- Clean version set
- Reduce bloat on disk
- Fedora currently offers the ability to mutate objects and create fixed versions. In OCFL, everything is immutable. How to reconcile this, and maintain Fedora functionality.
- Store everything in OCFL and make version logical structures on top of this
- Store only immutable content in OCFL
- Mutable content stored within OCFL's 'deposit' directory
- Fedora maintains mutable content
- Automatically periodically "flush" staged changes to OCFL
- OCFL versions would not be meaningful – requires logical versions
- There's a possibility that an object could never have a version. Is this okay?
- Auto-versioning should be toggle-able
- Islandora controls versioning – auto-versioning would be off by default
- Where does unversioned content live?
- OCFL 'deposit' directory is intended for short-lived version creation and not long-term storage
- OCFL 'deposit' directory space is out of spec and is up to the individual library to use it as it will
- Currently, you can delete version markers, but this is not possible if you store version markers in OCFL. Perhaps store version markers outside of OCFL?
- All changes stored in OCFL
- Fedora managed version file that maps OCFL versions to logical versions. This mapping is outside of the OCFL object.
- Pros about versioning every change in OCFL
- Easier to implement
- Easier to reason about
- Rebuildability is easier
- Cons about versioning every change in OCFL
- Binary bloat
- Inventory bloat
- OCFL versions are not presented in the API only Fedora versions are
- Some use Fedora to author content over a period of time. They want to version when the content is ready and not have a version of every change.
Actions
- Aaron Birkland to look explore notion of OCFL client with database as authoritative metadata source + asynchronous writing of the inventory.json file
- Peter Eichman and maybe Ben Pennell to make recommendations re transaction side car specification.
- Andrew Woods will look into java 11 transition