Time/Place

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

Attendees

Agenda

  1. Sprint Summary
    1. Updates on 
      1. External Content
      2. WebAC
      3. Binary Versioning
      4. CTS
  2. The fate of /fcr:fixity  endpoint:  should we continue to support it in 5.0?
  3. Getting to 5.0 
    1. Another sprint? 
    2. Everyone commit to a ticket or two this week?
    3. 5.x Documentation Effort
      1. 5.x Documentation Updates matrix
    4. Ecosystem tools dependent on the release:
      1. java client 
      2. camel tool kit  
      3. fcrepo4-vagrant
      4. import export tool
      5. api-x 
  4. : 

    1. Are we comfortable with messages emitted?

  5. ?

Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

  1. Sprint Summary
    1. Danny: Sprint successful.  Closed 30 issues. 11 Participants.  Major work to handling of binaries and their descriptions (overhaul really) – to their structure to support binary mementos.  Still some small issue around deleting of mementos nevertheless on the verge of declaring victory after some additional testing.  Congrats to Ben Pennell.  Major overhaul to WebAC.  WebAC piece ended up being bigger than expected, but hats off to Mohamed Mohideen Abdul Rasheed and Peter Eichman for this effort.
    2. Updates on 
      1. External Content

        1. Bethany – Got tests passing and rebased.  Working on getting binary memento tests to pass.  Hope to have PR later today or tomorrow AM.  Proxy and Copy should be covered.  Versioning of external content:  Has this scenario been addressed?

        2. Jared noted that one might version the metadata related to the External Content, but there was a general consensus that versioning content, proxied or otherwise, outside the repository was beyond the scope.

      2. WebAC
        1. Peter - Major refactoring into shiro and out of modeshape and fedora authorization delegates.  Intend to get back to a few of the remaining issues or get the code pushed up for someone else to bring to completion. Given how modeshape works, we will still need some implementation of an authorization provider for modeshape to set up the security context for modeshape, despite the fact that we are not doing the authorization in modeshape, because modeshape still needs to know “who” did something.  Mohamed has some work on this started.

      3. Binary Versioning

        1. Work merged into ‘master’. Worked out separation of binary and description.  With one command you can create a binary version and that automatically creates a version of the description. And then you can independently version them.  Work is in a good place.

      4. CTS

        1. Danny – CTS is getting there.  Should be in a good place by EOD to fix currently breaking tests, or to at least investigate the issues, and then it should be clear where to layer in the additional elements of the specification.

        2. Randall noted that it was initially difficult to translate written spec to a test, but newer patterns in CTS provides clearer path forward.

  2. The fate of /fcr:fixity  endpoint:  should we continue to support it in 5.0?
    1. There was a question surrounding this in Slack, presumably because the interaction for the digest feature in 5.0 is entirely Header-based and the 4.0 /fcr:fixity endpoint is superfluous.
    2. In the end, there is a notional consensus to remove the /fcr:fixity endpoint, but we should send note out to the list asking for feedback.

  3. Getting to 5.0 
    1. Another sprint? 
    2. Everyone commit to a ticket or two this week?

      1. Danny  - https://jira.duraspace.org/browse/FCREPO-2275?filter=14401  Grab a ticket and let’s see  if we can get ‘er done.

      2. If above tickets were closed, we'd be in alignment with spec.

      3. BUT definitely more work to do on Documentation and CTS.

    3. 5.x Documentation Effort
      1. 5.x Documentation Updates matrix

        1. Danny - Took every 5.x documentation page and set up a process around documentation review.  Seemed straightforward and less arduous than using Jira for this.  Put you name by a page and get crackin’.

        2. Kevin – If those who worked on specific elements of the API – fixity or versioning for example – could initially review the carried-over documentation that would be really helpful as those individuals will be most familiar with the new interaction patterns and/or API differences.

        3. Andrew – Perhaps if Peter and Mohammed could look at WebAC....

    4. Ecosystem tools dependent on the release:
      1. General agreement that a review of the existing ecosystem tools should be reviewed to determine whether there are any blockers or otherwise prioritize upgrading them.
      2. Noted that there are unlikely to be any 'blockers' but emphasized that the community might identify a number of very-nice-to-haves.
      3. Will take list to leadership group and community generally.
      4. List
        1. java client 
        2. camel tool kit  
        3. fcrepo4-vagrant
        4. import export tool
        5. api-x
        6. fcrepo4-exts

  4. : 

    1. Are we comfortable with messages emitted?

      1. TIME.  Noted we need to talk about this but discussion postponed.


Actions