...
- A. Soroka
- Jared Whiklo
- Bethany Seeger
- Yinlin Chen
- Doron Shalvi
- Benjamin Armintor
- Andrew Woods
- James R. Griffin III
- David Wilcox
- Allen Flynn
- Namita Bahulekar
- Longshou Situ
- Esmé Cowles
- Unknown User (acoburn)Martin Haye
Agenda
- Strange behavior of Binaries and NonRdfSourceDescriptions (see gist and comment below)
- Schedule special-topic meeting on Versioning Spec (pre-requisite reading: Memento spec)
- F4 plans for moving to Modeshape5
- Release candidate policy
- Can we cut a release for fcrepo-build-tools
- Upcoming release for fcrepo-camel
- Thoughts on multi-tenancy
- ...
Status of "in-flight" tickets
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 40 jqlQuery filter=13202 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
...
Please squash a bug!
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 40 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 40 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 40 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Minutes
...
4.5.1 RC-3 testing status
- Includes all known issues
- No outstanding tickets for RC4
- Sign-off from Hydra and Islandora on sanity tests
- Still need to run through tests based on exercises we do in workshops
- Plan to release 1 week from tomorrow
- This release was thoroughly tested
Strange behavior of Binaries and NonRdfSourceDescriptions
- Looks like we have agreement on expected behaviour
- Last modified date on binary source descriptions is problematic
- What should the behaviour be?
- Option 1: Collapse last modified info from binary and binary description into a single value
- Seems like a bad choice but fixes broken behaviour
- Option 2: Keep these values separate but distinguish between HTTP representation and resource representation
- Data from the headers is HTTP-specific: it concerns representations. Data from the body (RDF) is repository-specific: it concerns resources.
- Note: In the event that the binary itself is changed (e.g. via a PUT operation), it is expected that all last-modified dates would change: the fedora:lastModified date in the RDF would change, since the binary was modified, as would the HTTP headers corresponding to the binary. Since the RDF in the description would change (in addition to fedora:lastModified, the premis:hasMessageDigest would also change) the HTTP last-modified header corresponding to the RDF description would also need to change (since its representation changed).
- Should we distinguish between a change to the binary and a change to the description in the messaging framework?
- This will require further discussion. A binary and its description are 2 different HTTP resources but different aspects of the same Fedora repository resource
- Action: Continue this discussion at the committers meeting at OR2016
Schedule special-topic meeting on Versioning Spec
- We will move forward with spec docs one at a time
- Versioning appears to be ready to move forward
- Move into Git repo and use Respec tool
- There are 2 options for how versions are created
- Need agreement on this before we move forwrard
- Option 1: Indicate that a resource should be versioned. Any updates create a new version
- Option 2: A parallel resource is a versioning target. POSTing to that resource creates a snapshot on demand
- Action: Andrew will send out a Doodle poll to schedule the meeting
F4 plans for moving to Modeshape5
- Modeshape 5 has been released
- No longer uses Infinispan
- There is a ticket for moving to Modeshape 5
- A migration will be required
- A backup/restore operation is recommended
- Fedora exposes this capability already
- This capability will be deprecated in the future but for now it is useful
- We will need to update configurations/dependencies and do a lot of testing
- At what point will we support more than one release?
- One that supports Mode4 and one that supports Mode5
- Will we have parallel releases?
- If the migration is smooth, we should encourage everyone to upgrade
- If not, parallel releases may make more sense
- Should we use Mode5 to launch Fedora 5?
- Should we have separate releases for the implementations and the APIs?
- Need to get all the JCR stuff out of the API
- We would have 2 implementations at first: Mode4 and Mode5
- What would their version numbers be?
- Mode4 could be 4.x and Mode5 could be 1.x
- fedora-4.6.0-mode5-1.0.0
- This is an opportunity to separate the API from the implementation and encourage alternate implementations
- Need a new branch for Mode5
Release candidate policy
- Please review
Can we cut a release for fcrepo-build-tools
- Fewer lines of code in test suites
- Can we cut a new release?
- Need to update modules that use build tools directly
- Action: Aaron will create a ticket and cut a 4.4.1 release
Upcoming release for fcrepo-camel
- Done