Time/Place

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

Attendee

Agenda

  1. Upcoming Sprints
    1. Please sign up
    2. Sprint 1: Release 5.0
      1. Optimally we start Sprint 1 with a release candidate  
      2. Complete documentation
      3. Wrap up the compatibility test kit
    3. Sprint 2: Ecosystem Tools
      1. Camel Toolbox
      2. Java Client
      3. Import/Export
    4. What is the best way to prepare as a team?
  2. Getting to 5.0 Release Candidate
    1. 5.x Documentation Effort matrix
    2. In progress tickets
    3. Remaining external content (low-hanging: ie volunteers?, mini-sprint?) issues:


    4. All API Alignment Issues


  3. Fedora API Specification update
    1. Second Candidate Recommendation ready for publication!
    2. Sidecar specifications
      1. One-step fixity check -  github issue (create github repo in fcrepo4-labs)
      2. Atomic operations (move to fcrepo4-labs)
  4. Moving python client code into fcrepo4-labs
  5. <Add your agenda item here>

Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

  1. Upcoming Sprints 
    1. Still looking for contributors, please go ahead and add name to sprint.
    2. Sprints 1 and 2 are ambitious.  It may be too ambitious to put out version 5.0 after sprint 1; more likely to have it after sprint 2.
    3. Need to bring other tools, such as camel-toolbox and java-client, into alignment.
    4. The Import-Export combinations to be supported in 5.0 needs to be defined.
    5. UMD to take lead on camel-toolbox work.  Peter and Mohamed to support.  Josh to support testing TCK.
    6. Test suite only tests CRUD portion of API, and still needs to be completed.  Need tests for WebAC, others.  Simeon using Test suite as a tool to test Python implementation.
  2. Getting to 5.0 Release Candidate
    1. Timing
      1. Possible to have a release candidate ahead of Sprint 1?  May be difficult.  Danny graciously put together this agenda, based on some notion of realism.
      2. Sprint starts in September. 
      3. For community support, it helps to define in advance the work and timeframe involved.
    2. Release Priorities
      1. Level 1: Get 5.0 out, get TCK out
      2. Level 2: I/O export, toolbox, Java client
    3. Tickets
      1. FCREPO-2742: FCR ACL - Peter working.  Getting a HTTP 405 response.  In progress.  Andrew to look into hash resources, children as properties question.
      2. External content - have a mini sprint to address?
      3. FCREPO-2776 - Josh may investigate before sprint starts.
  3. Fedora API Specification update
    1. Second Candidate Recommendation ready for publication!  Will be posted to fedora.info.
    2. Not yet releasing as 1.0 spec until implementation and TCK is in place.  Will send one email regarding spec and another regarding implementation.
    3. Other features may be added to a future version of spec, such as 1.1 or 2.0.  The spec is intended to evolve to reflect the needs of the Fedora community.  Until then, these new features will be defined in sidecar specs.
    4. Sidecar specifications known so far:
      1. One-step fixity check -  github issue (create github repo in fcrepo4-labs)
      2. Atomic operations (move to fcrepo4-labs)
  4. Fixity design, spec and implementation
    1. Interest expressed in a one-step process, that does not require the client to have any responsibility to compute fixity.  What would this look like?
    2. Peter: we could hold an implementation in fcrepo-labs until there is broader community adoption, then move it to fcrepo-extensions.  This could be similar to how PDPs get rolled into Python releases.
    3. Currently there are three discussions regarding fixity:
      1. Want-digest header-based
      2. LDP container focused, post to container, resources persisted there.
      3. implementation of current Modeshape functionality (even in a post-Modeshape world), alignment with a RESTful Fedora API.
    4. Doron: Some fixity functionality could be better thought of as server configured functionality and not necessarily part of a client API.  For example, configuration to specify frequency of routine fixity checks for all items, to be performed regardless of client invocation.  A more turnkey solution would be nice.
    5. UMD and NLM to collaborate on design ideas.
    6. Andrew: This could also be a pluggable module delivered with core, or maybe an internal core module.
  5. Moving python client code into fcrepo4-labs
    1. At OR, interest was expressed to move this code into fedora-labs.  What is this process?

    2. Process: Do not fork or create a new repo, just transfer ownership to labs.