Time/Place
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
- Participant Code: 479307#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- IRC:
- Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #fcrepo on irc.freenode.net
- ? add slack channel info here?
Attendees
- Danny Bernstein
- Andrew Woods
- Peter Eichman
- Bethany Seeger
- Jared Whiklo
- Yinlin Chen
- Doron Shalvi
- Esmé Cowles
Agenda
- 4.7.5 Release
- bringing it over the finish line:
- Sign up for API Alignment sprints by adding your name
- Delta Document Progress Review
- Compatibility Test Suite
- Any remaining questions?
- ?
Ticket Summaries
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Action Items
- Danny Bernstein add a JIRA for deprecating/removing the pairtree retrieval behavior
- Andrew Woods add the external content topic to spec editors call agenda
- Danny Bernstein add the Java version support topic to the committers call agenda
Minutes
- 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