Time/Place

• Friday, Sept 20, 2019
• Time: 10: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

• Join fedora-project.slack.com on the "sprints" channel

Attendees and availability:

1. Rosalyn Metz
2. Aaron Birkland
3. Danny Bernstein
4. Peter Winckles
5. Jared Whiklo
6. Ben Pennell

Agenda

1. Discuss specific concerns in depth with Editors
2. Identify method for moving forward
3. Discuss how to message to Fedora Steering and Leaders

Notes

1. Context Setting
   1. After initial design meetings (VA Beach): content would be pushed into OCFL when a version is created, because that's immutable (which lines up with OCFL).
   2. Stuff waiting for OCFL would be co-located at the object root; but the spec was changed to have it at the storage root; question came up about whether or not there is a need to have a second storage environment with content outside of OCFL.
   3. Community concerns: stuff will be outside OCFL.
   4. Well maybe we can put everything in OCFL, even things that are un-versioned.  Which would mean that you could end up with thousands of versions.  There are storage issues related to this because the inventory.json file grows rapidly with lots of versions.
   5. Considerations: Most recent version is mutable; and once a new version is created, the past version is written to OCFL and the new version now becomes mutable.
2. Diving into concerns around stuff being outside OCFL.
   1. People who use Fedora and never use the versioning mechanism, then content may never end up in OCFL.
   2. How does this impact Fedora 3?
   3. Transactions - as people are making changes they are staged and not complete, this would not be in OCFL.
   4. Anything they have committed to Fedora should be preserved.
   5. Technically the spec doesn't describe a deposit directory <validate this>.  And because of that the deposit directory is out of spec, which means the version you are creating is not in OCFL.
   6. Is it possible that if we make the most recent version mutable we are breaking something else.

Options to consider:

1. Change the spec to support a Mutable HEAD. A Mutable HEAD is valid OCFL (inventory.json etc), but should be ignored by replication. The spec should make clear that the Mutable HEAD is not at rest.
2. Specify the contents of the  /deposit directory in a separate RFC.