Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Agenda

  1. Update from "Alignment to Spec" sprint

    1. Epic in Jira: 
      Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2582
    2. Versioning and Auth design subgroup: Versioning /- Authorization Design
    3. Breaking changes policy, tickets: 
      Jira
      serverDuraSpace JIRA
      jqlQueryfilter=14303
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
  2. Preservation specification
  3. Modeshape 5.4 upgrade:
    Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2581
    1. Next fcrepo 4.7 maintenance release
  4. Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2585
     : question about supported types
  5. Wrapping up fcrepo-import-export-verify: https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/48
  6. Status of "in-flight" tickets

  7. Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=13202
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


...

  • 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

...