Agenda

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
1. Proposal (based on group discussion)
  1. Jira
    server DuraSpace JIRA
    serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
    key FCREPO-2671
  2. Jira
    server DuraSpace JIRA
    serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
    key FCREPO-2672
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? 
```
  Code Block1. by default, minted identifiers should not have any pairtree structure 2. by supplying a system property, the current pairtree generation can be restored 3. retrieving the pairtree nodes should either a) require a second system property or b) not be supported at all
Jira
server DuraSpace JIRA
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
key FCREPO-2520
```
 - Also move forward with creation-side resolution?
```
External Content: Redirect or Proxy? on fedora-tech
1. (TBD only is appropriate people are on the line)
Java release schedule and compatibility planning
1. See http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html
  1. "With a release every six months, it is important to decide on an approach to the release train."

Ticket Summaries

Please squash a bug!
Expand
Jira
server DuraSpace JIRA
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues 20
jqlQuery filter=13122
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Tickets resolved this week:
Expand
Jira
server DuraSpace JIRA
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues 20
jqlQuery filter=13111
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Tickets created this week:
Expand
Jira
server DuraSpace JIRA
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues 20
jqlQuery filter=13029
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

4.7.5 Release

Kevin Ford's issue has been resolved - was due to hardcoded config in the release artifact
Solr issues have been observed in testing
- Solr config is set to use autosoftcommit: 1000ms
- Some custom predicates do not get indexed
- Likely all is well

Action Items

Danny Bernstein add a JIRA for deprecating/removing the pairtree retrieval behavior
ACTION: Would be great if Aaron Birkland could perform API-X tests
ACTION: Jared Whiklo to test CLAW
ACTION: Andrew Woods to add build scripts to testing wiki
ACTION: Bethany Seeger to do some Vagrant testing
ACTION: Jared Whiklo suggesting update to fcrepo4-vagrant to reduce toolbox retries to 1 -
Jira
server DuraSpace JIRA
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
key FCREPO-26692673
ACTION: Kevin Ford to retest items that have 's
ACTION: Joshua Westgard to test postgres
ACTION: Andrew Woods to reach out to Carrick Rogers re:RC testing
ACTION: Jared Whiklo to help with release on week of the Feb 12th

API Alignment Sprints

Please sign-up

Pairtree/Appletree going forward

Proposal:
1. by default, minted identifiers should not have any pairtree structure
2. by supplying a system property, the current pairtree generation can be restored
3. retrieving the pairtree nodes should either a) require a second system property or b) not be supported at all
Peter Eichman is working on a document specifying behavior of container segmentation
There is concern about support for the "pairtree workaround" going into 5.0.0

ACTION: Danny Bernstein to create a Jira for decisions 1&2

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. 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)
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
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
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
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
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
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
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

Page tree

Versions Compared

Old Version 6

New Version Current

Key

Agenda

Ticket Summaries

Minutes

4.7.5 Release

Action Items

API Alignment Sprints

Pairtree/Appletree going forward

Minutes

Page tree

Page History

Versions Compared

Old Version 6

New Version Current

Key

Agenda

Ticket Summaries

Minutes

4.7.5 Release

Action Items

API Alignment Sprints

Pairtree/Appletree going forward

Minutes