This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Dial-in Number: (712) 775-7035
- 4.7.5 release testing - discussion of where things stand
- Sign up for API Alignment sprints by adding your name
- Delta Document, Sprint Optimization, and due dates
- Compatibility Test Suite
- Pairtree/Appletree options
Proposal (based on group discussion)
As yet undecided
when pair tree node creation is enabled should performing a GET or HEAD
return non-pair tree children as they do now?
return a 400 series message (404 or 405)?
If both 1 and 2, what should the default behavior be?
- Also move forward with creation-side resolution?
- External Content: Redirect or Proxy? on fedora-tech
- (TBD only is appropriate people are on the line)
- Java release schedule and compatibility planning
- See http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html
- "With a release every six months, it is important to decide on an approach to the release train."
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
- 4.7.5 release testing on track
- 1-2 tests for Danny Bernstein to complete
- Esme: will do RC-2 testing with ActiveFedora/Hyrax, or find someone to delegate to
- Andrew Woods: contacted Carrick Rogers about testing on their custom fedora with RC-2
- release is slated for next week (Feb 12)
- API Alignment Sprint: if you haven't signed up for API alignment sprint, please do so
- delta document for documenting the differences between 4.7.5 and 5.0
- make it a goal to fill out each section by next week's call
- identify items that are out of alignment
- Peter: authz
- Danny will ping Aaron Birkland about nofitications
- Danny: versioning
- Jared & Yinlin: resource management
- keep in mind the spec may have been updated; make sure section numbers match up
- compatibility test suite: needs work
- try running the compatibility suite
- add git issues as feedback
- code review would be extra helpful
- mainly covers section 3 (resource management)
- cross-check test suite report to manual test results
- "trust but verify"
- Yinlin: Python vs. Java test suite?
- Andrew: we will focus on the Java version as the official test suite
- close to landing pairtree issue
- remaining question: what is the behavior of the pairtree nodes?
- Esme: we need to support the current behavior
- Aaron Birkland feels strongly that pairtree nodes should not resolve
- Andrew: concerned about complexity of code and introducing bugs
- Bethany: could we only have 1 setting?
- Andrew: need to support migration of existing pairtrees, so generation needs to be separate from retrieval
- Esme: minting behavior is easy and tidy; UUID-only minter should be very easy to write
- MIME type validation
- Bethany: putting in a check of object values in PUT/PATCH requests that mime types are syntactically correct
- ebucore:hasMimeType is treated as a special case since it is used as the content-type of a binary resource on GET
- external content design: send over to spec team for further work
- Peter, Esme, Doran agree
- Peter: start from the draft Prefer header spec that Ben Pennell created
- Doran: NLM has a particular interest of this
- Doran: there could be interplay between this and the Oxford Common File Layout
- Andrew: need to make sure we capture real uses cases
- changes in the Java release schedule
- new major versions every 6 months
- LTS releases
- Oracle seems to be expecting folks to start paying for Java releases that last longer than 6 months that aren't LTS releases
- we need to prepare for supporting new Java releases more quickly
- Java 8 will be LTS
- Java 11 will be LTS
- Andrew: do we support LTS releases only? or short-term releases as well?
- Esme: LTS versions seem like a better bet
- transition times between LTS will be smaller
- need to prepare for new Java versions farther in advance
- Danny: what is the history of Java updates?
- Andrew: Policy - Supported JVM
- Esme: several issues
- many repos set up once and then not update to maintain stability as long as they can
- desire for compatibility with new versions of Java
- new language features that implementors might want to use
- Andrew: users tend to stability, developers tend to latest
- Esme: supporting the most stable/predictable Java makes the most sense for the user base
- Esme: keeping up with latest release is a nice-to-have, but user needs are prioritized
- Danny: may be able to compile Java 9 code to target a Java 8 JVM
- Andrew: start with consensus-building on tech call and the committers call
- Danny: next steps: clarify the different pathways and get feedback from committers and community