Page tree
Skip to end of metadata
Go to start of metadata


This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to's the info:



  1. Update from "Alignment to Spec" sprint

    1. Epic in Jira:  FCREPO-2582 - Getting issue details... STATUS
    2. Versioning and Auth design subgroup: Versioning - Authorization Design
    3. Breaking changes policy, tickets: 

      T Key Summary Assignee Reporter P Status Resolution Created Updated Due

  2. Preservation specification
  3. Modeshape 5.4 upgrade: FCREPO-2581 - Getting issue details... STATUS
    1. Next fcrepo 4.7 maintenance release
  4. FCREPO-2585 - Getting issue details... STATUS  : question about supported types
  5. Wrapping up fcrepo-import-export-verify:
  6. Status of "in-flight" tickets
  7.  Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due

Ticket Summaries

  1. Please squash a bug!

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution

  2. Tickets resolved this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution

  3. Tickets created this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution


  • Item 1.a-b Aaron Birkland: alignment to spec sprint
    • started this week
    • tasks based on delta doc
    • well into process
    • open questions about memento + WebAC
      • determine difference between spec and current implementation
      • what issues need to be raised to broader community
    • Bethany Seeger: design issue: how do we deal with versioning in ACLs?
      • don't have many use cases yet
      • how do DELETEs affect versions?
        • delete is optional in the spec
        • is delete required? does a delete delete all versions of a resource
      • Ben Pennell: issues posted back to spec group
        • current spec confusing with regards to creating new versions
      • Andrew Woods: proposal: do not support individual ACLs for Mementos; all Mementos share the same ACL
        • Peter Eichman: only use case is if the original version of a resource has sensitive info, made public after scrubbing, but original resource shouldn't be exposed
          • solution is to create a new resource not a version for scrubbing
        • Aaron Birkland: ACL for a resource, within the ACL have Authz rules for different mementos
        • Andrew Woods: mementos are immutable
        • Aaron Birkland: spec doesn't require a triple on the resource
          • Link header is used for ACL discovery
          • do you have to freeze the value of the Link header when you make a memento?
          • Andrew Woods: we should put a stake in the ground; shall we extend immutability to its Link header?
        • Andrew Woods: possible model: memento gets ACL from its LDPCv container; if none should we default to global default or defaults to walking up the tree
        • Bethany Seeger: LDPCv++, allows different authz rules on resource vs. public
        • Aaron Birkland: need to engage community verify that stakes in the ground are acceptable
          • once the subgroup has an algorithm for determining ACL for memento it should go back to the spec group, since it won't be exactly the WebAC algo
        • Andrew Woods: should we bring in Herbert (Memento author) to consult? pre-volunteed to participate
        • Bethany Seeger: identifying non-controversial pieces of Authz+Versioning and creating tickets
        • Andrew Woods: start with "ACL on container" algo?
        • Andrew Woods: delete of versions?
          • Bethany Seeger: it's a MAY in the spec, current fedora behavior is delete a resource
          • Andrew Woods: do we tie memento lifecycle to resource lifecycle? deletes all versions, what does the community think?
            • Jared Whiklo: yes
            • Esmé Cowles: yes
            • Danny Bernstein: AWS doesn't tie versions to resource
            • Ben Pennell: no; memento allows original delete but retain history; good to look at how fedora's expected usage of versioning differs from web archiving and amazon
            • Aaron Birkland: Wouldn't a safe way to delete a resource + versions be to DELETE the LDPCv (to delete versions implicitly), then the LDPRv?
          • Andrew Woods: when you have versioned resource with LDP children, do we version the resource or the whole tree?
            • Peter Eichman: versioning the whole tree makes the most sense
            • Danny Bernstein: in abstract, yes; but potential for explosion of storage needs may be practically problematic
            • Aaron Birkland: tree based versioning creates mementos for all children; current versioning copies all children, but those children aren't versioned
            • Bethany Seeger: version trees, but requires work
            • Andrew Woods: consensus is to version trees
            • Bethany Seeger: safest bet to version children in a way they know about; needs to get fixed in code
            • Aaron Birkland: that sort of fix may change how we use modeshape for versions significantly
            • Ben Pennell: if you do that then you get the multiple containment issue though (two LDPCv's would contain the version of b)
            • Jared Whiklo: what about outbound links in addition to children? does this end with a snapshot of the entire repo?
              • Aaron Birkland: We could also do baby steps and start with single-resource versioning, then figure out trees :)
              • Jared Whiklo: not advocating for whole repo snapshots nor even necessarily versioning linked resources, just trying to find the margins
      • we will continue this discussion in special topic conversations on the Authz+Versioning issues
      • Andrew Woods: continue with Mode versioning, or roll our own versioning system, memento implementation
        • Aaron Birkland: probably abandon Mode
        • Jared Whiklo: agree
        • Ben Pennell: not sure about taking a default approach of making versioning totally backwards incompatible with fcrepo 4 by not initially taking a tree version approach
  • Andrew Woods will be gone next week, call for facilitator?
  • Item 1.c: Aaron Birkland: flagging things that break backwards compat
    • taking conservative approach, but not requiring backwards compat
    • Andrew Woods: community expectation is there will be breaking changes
      • limited to API is best
      • helpful to have a 4.7.5 release with deprecation notices, and other bugfixes
  • Item 2: Preservation spec
    • Andrew Woods: there is ongoing interest in specifying what is actually on disk for Fedora, for implementations that write to disk
  • Item 3: Mode 5.4/next fcrepo 4.7 release
    • Peter Eichman: supports 4.7.5, Mode 5.4 so far seems to work in UMD's testing, avoids stuck threads issue
  • Item 4: deferred to IRC

  • No labels