...

1. Danny Bernstein
2. Jared Whiklo 
3. Andrew Woods 
4. Peter Winckles  
5. David Wilcox  
6. Ben Cail
7. Thomas Bernhart 
8. Daniel Lamb
9. Ben Pennell

Agenda

1. Announcements

2. Sprint Post Op Reflections
   1. Sprint board
   2. Remaining items?
   3. Demo

3. 1. PRs closed this last week:
      1. (no JIRA): https://github.com/fcrepo4/fcrepo4/pull/1662 Ben Pennell
      2. (no JIRA): https://github.com/fcrepo4/fcrepo4/pull/1663 Peter Winckles
      3. (no JIRA): https://github.com/fcrepo4/fcrepo4/pull/1665 Peter Winckles

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

          Jared Whiklo
   2. New tickets/bugs: 

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

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

4. Committers leaders call upshot (5 mins)
   1. Follow-on meeting next Wed @11am ET - 2020-04-29 - Fedora Leaders - Committers Meeting
5. fcrepo4-docker and fcrepo-docker status update
6. Pre-Sprint focus:
   1. simple search plan
      1. What do we plan to support in 6.0.0? 
      2. 2019-02 Fedora Design Summary
      3. Query Service Specification
      4. Samvera / Valkyrie Queries
7. Fedora 6 testingWhat's up next? 
8.  2020 Sprints - Fedora 6#2020SprintsFedora6-May4-8
9. Feature tracking
Next sprint focus?
10. webacs
11. ...
...
12. Containment Index
    1. How to handle SQL differences (H2, MySQL, PostgreSQL) - pluggable connectors?
13. Housekeeping PRs
    1. https://github.com/fcrepo4-labs/fcrepo4-docker/pull/38
    2. https://github.com/fcrepo4/fcrepo4/pull/1628 
14. Fedora 6 testing
15. Committers/Leaders call topics
16. Roadmap?

17. <Add your topic here>

    Expand
    title Tickets resolved this week...
    Jira server DuraSpace JIRA jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

    
    

...

1. In Review

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13100 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

2. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

3. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

4. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Notes

Announcements

...

1. Zoom waiting room is now enabled – Let David know if it's a problem

...

1. Sprint board
   1. Just a couple of tickets still in review
2. Reflections on sprint? Changes for next sprint?
   1. Ben: Quiet but went well. Short week, due to holiday.
   2. Daniel: Agrees with Ben. Scope seemed appropriate. Next sprint stay conservative. Separate lanes worked well.
   3. Jared: Went well. Liked the separate lanes.
   4. Peter: Same
3. JMS events done?
   1. ResourceTypes are not currently correct: https://jira.lyrasis.org/browse/FCREPO-3279
      1. Ben says that there was some thought that you might want to differentiate between user managed and server managed types, which is why you might want to resolve the types at render time.
      2. Jared says that some of the types are currently being added in getTriples, so perhaps the code should just be moved to getTypes and have getTriples call it.
   2. PATCH isn't implemented so those events aren't there yet
4. Demo
   1. Features:
      
      1. Rebuild
      2. Messaging
      3. Transactions
   2. Rebuild will be the most interest to people.
      1. Shouldn't be too technical
   3. Andrew thinks it'd be good to demo the relationship between Fedora and OCFL versions and all of the different ways that they're created.

...

1.  2020 Sprints - Fedora 6#2020SprintsFedora6-May4-8
2. Feature tracking
3. Next sprint focus?
   1. webacs
      1. Might be less important than Simple Search
      2. Maybe if someone from Maryland was on the sprint
   2. PATCH
      
      1. Jared: Thinks it will be easier without Modeshap
   3. DELETE
   4. Vanilla OCFL rebuild
      1. No one has vanilla currently, so the feature might that be that high of priority
      2. Migration utils produce Fedora OCFL and/or Vanilla OCFL?
      3. What does the community think? How highly valued is running on vanilla OCFL?
      4. How about a tool for converting vanilla OCFL to Fedora OCFL?
      5. Peter: It doesn't seem right to run Fedora on Vanilla OCFL but have the new objects it produces be Fedora OCFL.
   5. Simple Search
      1. Andrew: People want this feature; we haven't done it before so there's risk and unknown; might be worth doing early
      2. Ben: Agrees it'd be good to figure out early – figure out its integrations with other components

...

1. How to handle SQL differences (H2, MySQL, PostgreSQL) - pluggable connectors?

...

1. Lots of good work happening this week
2. New bug tickets

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

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

      1. Andrew used git-bisect to pin down the error
      2. Getting the build to work with IntelliJ

Leaders/Committers Call

1. Follow-up meeting scheduled for next Wednesday
2. Setting context for vanilla-rebuild functionality
   1. Supporting both plain OCFL and Fedora-specific OCFL for read/write, rebuild, etc. would be challenging
   2. If Fedora leaves Fedora-specific data in OCFL directories this might be unexpected/unwanted behaviour
      1. However, this extra data could be stored in a .fcrepo directory which would be fairly easy to remove if desired
      2. The .fcrepo directory may actually be useful for providing context of the previous state of the resources within a Fedora repository
      3. Reaction from OCFL editors: why now use the extensions directory?
         1. Put .fcrepo inside extensions outside the context of the OCFL Object
         2. Risks complexity, splitting metadata in different locations
   3. Fedora should be able to import and read vanilla OCFL without adding specific Fedora data
      1. Fedora would add Fedora-specific data in order to manage/write to the content on disk
      2. Documentation should be clear about what operations on vanilla OCFL objects do and do not add Fedora-specific data
3. 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:
   1. common to ocfl objects (timestamps, a checksum, etc),
   2. useful for a linked data platform (interaction models, containment),
   3. fedora specific (external binary location, binary details, creator/modifier details),
   4. user provided RDF/binary content.
4. 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
5. Proposal: Fedora doesn't know how to upgrade from read-only vanilla OCFL. Upgrading to read/write would require a migration utility
   1. In this case the repository would be in read-only mode - can't create new resources without running the migration utility
   2. Migration would be in-place - adding new versions with Fedora-data
6. Two different concerns: software maintainability vs. long-term preservation
7. Ben C: Desire for basic read/write HTTP layer over OCFL
   1. Doesn't want .fcrepo directory

Fedora Docker Implementation

1. Updated to Fedora 5.1.0, fixed some issues
2. When/how are Fedora snapshots pushed to the Maven repository?
   1. Every GitHub commit triggers Jenkins. Successful builds result in Sonatype snapshots
      1. This is currently broken but should be fixed soon
   2. It would make sense to trigger the Docker pipeline as part of the Travis workflow once Travis has been configured to publish snapshots

Actions

Actions

•  Danny Bernstein  to create JIRA to update spec for response codes (see: 187171682)
•  Danny Bernstein to ensure that a JIRA exists for scenario of transaction does not succeed completely, but rollback does succeed (see: 187171682 2020-04-23 - Fedora Tech Meeting)
•  Ben Pennell to create ticket to use OCFL optimistic locking in transactions (see: 187171682) 2020-04-23 - Fedora Tech Meeting)

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

•  Peter Winckles to create a JIRA to investigate support for optimistic locking and mutable head (see: 187171682) Danny Bernstein to ensure JIRA exists for vanilla OCFL rebuild (see: 187171682 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
  

...