Time/Place

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

Attendees 

Agenda

  1. Update from "Alignment to Spec" sprint

    1. Epic in Jira:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Versioning and Auth design subgroup: Versioning - Authorization Design
    3. Breaking changes policy, tickets: 
      type key summary assignee reporter priority status resolution created updated due

      Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Preservation specification
  3. Modeshape 5.4 upgrade: Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    1. Next fcrepo 4.7 maintenance release
  4. Unable to locate Jira server for this macro. It may be due to Application Link configuration.  : 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. type key summary assignee reporter priority status resolution created updated due

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ticket Summaries

  1. Please squash a bug!

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

  • 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

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.