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/j/396037251
- Meeting ID: 396 037 251
- Find your local number: https://lyrasis.zoom.us/u/ad6Xb7q3ia
Join fedora-project.slack.com on the "tech" channel
- Self-register at: http://slack.fcrepo.org/
Attendees
- Danny Bernstein
- Jared Whiklo
- Andrew Woods
- Peter Winckles
- David Wilcox
- Ben Cail
- Thomas Bernhart
- Daniel Lamb
- Ben Pennell
Agenda
Announcements
- PRs closed this last week:
- New tickets/bugs:
- Committers leaders call upshot (5 mins)
- Follow-on meeting next Wed @11am ET - 2020-04-29 - Fedora Leaders - Committers Meeting
- fcrepo4-docker and fcrepo-docker status update
- Pre-Sprint focus:
- simple search plan
- What do we plan to support in 6.0.0?
- 2019-02 Fedora Design Summary
- Query Service Specification
- Samvera / Valkyrie Queries
- simple search plan
- Fedora 6 testing
- Containment Index
- How to handle SQL differences (H2, MySQL, PostgreSQL) - pluggable connectors?
- Housekeeping PRs
- Fedora 6 Roadmap?
<Add your topic here>
Tickets
In Review
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Notes
Announcements
- Lots of good work happening this week
- New bug tickets
- Andrew used git-bisect to pin down the error
- Getting the build to work with IntelliJ
Leaders/Committers Call
- Follow-up meeting scheduled for next Wednesday
- Setting context for vanilla-rebuild functionality
- Supporting both plain OCFL and Fedora-specific OCFL for read/write, rebuild, etc. would be challenging
- If Fedora leaves Fedora-specific data in OCFL directories this might be unexpected/unwanted behaviour
- However, this extra data could be stored in a .fcrepo directory which would be fairly easy to remove if desired
- The .fcrepo directory may actually be useful for providing context of the previous state of the resources within a Fedora repository
- Reaction from OCFL editors: why now use the extensions directory?
- Put .fcrepo inside extensions outside the context of the OCFL Object
- Risks complexity, splitting metadata in different locations
- Fedora should be able to import and read vanilla OCFL without adding specific Fedora data
- Fedora would add Fedora-specific data in order to manage/write to the content on disk
- Documentation should be clear about what operations on vanilla OCFL objects do and do not add Fedora-specific data
- Fedora makes assumptions in the absence of specified details based on the platform needs. It seems like there are multiple categories of info that are relevant to different purposes, such as:
- common to ocfl objects (timestamps, a checksum, etc),
- useful for a linked data platform (interaction models, containment),
- fedora specific (external binary location, binary details, creator/modifier details),
- user provided RDF/binary content.
- In the last design document, all of those details were going into .fcrepo except for the last one. Some can be derivable, some only matter in some contexts
- Proposal: Fedora doesn't know how to upgrade from read-only vanilla OCFL. Upgrading to read/write would require a migration utility
- In this case the repository would be in read-only mode - can't create new resources without running the migration utility
- Migration would be in-place - adding new versions with Fedora-data
- Two different concerns: software maintainability vs. long-term preservation
Actions
- Danny Bernstein to ensure that a JIRA exists for scenario of transaction does not succeed completely, but rollback does succeed (see: 2020-04-23 - Fedora Tech Meeting)
- Ben Pennell to create ticket to use OCFL optimistic locking in transactions (see: 2020-04-23 - Fedora Tech Meeting)
- Peter Winckles to create a JIRA to investigate support for optimistic locking and mutable head (see: 2020-04-23 - Fedora Tech Meeting)
- Who: Clarify in documentation that multiple simultaneous writes to OCFL are not supported
- Who: After team has a chance to comment, send Ghost Node idea to general community for feedback
- Who: Decide who works on what in the next sprint