...

1. Announcements
   1. 2020 Q1 Sprint Doodle: https://doodle.com/poll/es7nwdppt94rv2pz
      1. Need more publicity for the doodle poll and try to get more signups
   2. CNI Update

      1. https://wiki.lyrasis.org/display/FF/2019-12-11+-+CNI+Fedora+Leadership+Group+Meeting happened

      2. There is lots of support for Fedora 6 and making sure it is a success, and a desire for strong performance and scale testing before release.  Expectations are high for a quality release without any pressure for providing an aggressive timeline.
2. State of the development

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-3155

      Questions exist about the timing of id creation (fedora vs ocfl) during the rebuild process.  Moving conversation outside of the meeting due to time constraints.

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-3156

      Gives people an option as to how they mint new identifiers.

   3. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-3139

      Need a good pattern for mutating duplicate file names so they don't collide.
   4. Containment Index
3. Fedora 6 Demo
   1. Gauging the commitment level of folks during the holiday season to see if we can meet the goal of having a demo to show off as soon as possible.  Danny Bernstein and Andrew Woods will spend time over the break working on it and everyone else who is available will do what they can to bring this over the finish line.
4. Open Questions

   1. What to do with Pair Trees?

      Code Blockfrom last week: * probably not a need for it; * it was a performance hack with Fedora 6 that probably should go away * Aaron raises question about Fedora 4 to 6 migration of pair

      -trees

      * three options: collapse the pair-tree, retain pair-tree as containers, or retain Fedora 4 behavior * is there deployed Samvera behavior that depends on pair-tree nodes?

      : Didn't get around to it

   2. Multi-tenancy question:  Would it be possible to think about a single fedora supporting multiple storage roots?  ie one storage root maps to each top level container?

   <>

   1.   The basis is laid out via LDP containment and WebAC policies, but there still remain downstream considerations.  e.g. import/export'ing for an individual tenant, etc...

Actions

•  Clarify in in documentation that multiple simultaneous writes to OCFL are not supported

...