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 (out)
- Peter Eichman
- Joshua Westgard
- Ben Pennell
- Jared Whiklo
- Bethany Seeger
- Aaron Birkland
- Paul Cummins
Part 2:
Agenda
- Announcements
- Check-in regarding the double meeting format
- Status of https://github.com/pwinckles/ocfl-java-parent move into ocfl Github repo
- Opportunities to chip in:
- API Test Suite PRs
- Minimal 4 →5 migration needs testing and code review:
- API Test Suite PRs
- Update on Fedora 6 Pilots
- Sprint Planning
- 6.0 Architecture Review
- Versioning review from last week:
- Clarification of the proposal:
- OCFL transactions always result in new versions; we will not support unversioned content in Fedora
- From Fedora's point of view, the current state of a resource is the most recent version (ie HEAD)
- By default Fedora will display only "significant" versions in the list of mementos.
- "Significant versions" are OCFL objects that contain a marker file in the content directory (possibly something like content/.fcrepo/memento)
- Implication: versions cannot be removed ( because removing content from OCFL is likely to be controversial).
- Questions:
- Is it important to be able to have Memento timestamps synchronized across a multi-object transaction? In other words, are users going to want to be able to version changes across a single time-slice?
Ie:
http://localhost:8080/rest/object1/fcr:versions/20190822122001
http://localhost:8080/rest/object2/fcr:versions/20190822122001
http://localhost:8080/rest/object3/fcr:versions/20190822122001
- Is it important to be able to have Memento timestamps synchronized across a multi-object transaction? In other words, are users going to want to be able to version changes across a single time-slice?
- Clarification of the proposal:
- Multi-object transaction implementation ideas
- Versioning review from last week:
- Transaction Sidecar Spec Update
- 6.0 Architecture Review
- Status on organizing a Fedora documentation review
- Your topic here...
Tickets
In Review
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Notes
OCFL Java Client - let's get Peter Winckles and Aaron Birklandtogether for a discussion about a common java ocfl client interface / interaction model - hopefully we can discuss in part two of today's meeting.
Designed outcome: a java interface that will support both the java client and a JNI-wrapped Go Client.
Bethany Seeger : will take a look at Greg Jansen 's PR.
Danny Bernstein to add a discussion point around API Test Suite modifications and overall spec compliance discussion.
Joshua Westgard to look into fcrepo-upgrade-utils PR the next week.
Danny Bernstein to run upgrade routine on sample (e.g. plant patents ) datasets
Paul Cummins raising the concern about bloat with respect automated versions. He would have to change the client interaction with Fedora to prevent bloat. "Copy into new OCFL object + Delete old OCFL object" mechanism for removing unwanted object history is an acceptable solution.
There was consensus on the new versioning proposal and its implications.
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
