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. 4.7.5 release testing - discussion of where things stand
  2. Sign up for API Alignment sprints by adding your name
  3. Delta Document,  Sprint Optimization, and due dates
  4. Compatibility Test Suite 
  5. Pairtree/Appletree options
    1. Proposal (based on group discussion)

      1. FCREPO-2671 - Getting issue details... STATUS

      2. FCREPO-2672 - Getting issue details... STATUS
    2. As yet undecided
      1. when pair tree node creation is enabled should performing a GET or HEAD
        1. return non-pair tree children as they do now?
        2. return a 400 series message (404 or 405)?
      2. If both 1 and 2, what should the default behavior be? 
  6. FCREPO-2520 - Getting issue details... STATUS
     - Also move forward with creation-side resolution?
  7. External Content: Redirect or Proxy? on fedora-tech
    1. (TBD only is appropriate people are on the line)
  8. Java release schedule and compatibility planning
    1. See
      1. "With a release every six months, it is important to decide on an approach to the release train."

Ticket Summaries

  1. Please squash a bug!

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution

  2. Tickets resolved this week:

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution

  3. Tickets created this week:

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution

Action Items


  1. 4.7.5 release testing on track
    1. 1-2 tests for Danny Bernstein to complete
    2. Esme: will do RC-2 testing with ActiveFedora/Hyrax, or find someone to delegate to
    3. Andrew Woods: contacted Carrick Rogers about testing on their custom fedora with RC-2
    4. release is slated for next week (Feb 12)
  2. API Alignment Sprint: if you haven't signed up for API alignment sprint, please do so
  3. delta document for documenting the differences between 4.7.5 and 5.0
    1. make it a goal to fill out each section by next week's call
    2. identify items that are out of alignment
      1. Peter: authz
      2. Danny will ping Aaron Birkland about nofitications
      3. Danny: versioning
      4. Jared & Yinlin: resource management
    3. keep in mind the spec may have been updated; make sure section numbers match up
  4. compatibility test suite: needs work
    1. try running the compatibility suite
    2. add git issues as feedback
    3. code review would be extra helpful
    4. mainly covers section 3 (resource management)
    5. cross-check test suite report to manual test results
    6. "trust but verify"
    7. Yinlin: Python vs. Java test suite?
    8. Andrew: we will focus on the Java version as the official test suite
  5. close to landing pairtree issue
    1. remaining question: what is the behavior of the pairtree nodes?
    2. Esme: we need to support the current behavior
    3. Aaron Birkland feels strongly that pairtree nodes should not resolve
    4. Andrew: concerned about complexity of code and introducing bugs
    5. Bethany: could we only have 1 setting?
    6. Andrew: need to support migration of existing pairtrees, so generation needs to be separate from retrieval
    7. Esme: minting behavior is easy and tidy; UUID-only minter should be very easy to write
  6. MIME type validation
    1. Bethany: putting in a check of object values in PUT/PATCH requests that mime types are syntactically correct
    2. ebucore:hasMimeType is treated as a special case since it is used as the content-type of a binary resource on GET
  7. external content design: send over to spec team for further work
    1. Peter, Esme, Doran agree
    2. Peter: start from the draft Prefer header spec that Ben Pennell created
    3. Doran: NLM has a particular interest of this
    4. Doran: there could be interplay between this and the Oxford Common File Layout
    5. Andrew: need to make sure we capture real uses cases
  8. changes in the Java release schedule
    1. new major versions every 6 months
    2. LTS releases
    3. Oracle seems to be expecting folks to start paying for Java releases that last longer than 6 months that aren't LTS releases
    4. we need to prepare for supporting new Java releases more quickly
    5. Java 8 will be LTS
    6. Java 11 will be LTS
    7. Andrew: do we support LTS releases only? or short-term releases as well?
    8. Esme: LTS versions seem like a better bet
    9. transition times between LTS will be smaller
    10. need to prepare for new Java versions farther in advance
    11. Danny: what is the history of Java updates?
    12. Andrew: Policy - Supported JVM
    13. Esme: several issues
      1. many repos set up once and then not update to maintain stability as long as they can
      2. desire for compatibility with new versions of Java
      3. new language features that implementors might want to use
    14. Andrew: users tend to stability, developers tend to latest
    15. Esme: supporting the most stable/predictable Java makes the most sense for the user base
    16. Esme: keeping up with latest release is a nice-to-have, but user needs are prioritized
    17. Danny: may be able to compile Java 9 code to target a Java 8 JVM
    18. Andrew: start with consensus-building on tech call and the committers call
    19. Danny: next steps: clarify the different pathways and get feedback from committers and community
  • No labels