...
- Nick Ruest
- Aaron Coburn
- Osman Din
- Daniel Lamb
- Michael Durbin
- Kevin S. Clarke Stefano Cossu
- Yinlin Chen
- Nianli Ma
- Andrew Woods
- Jared Whiklo
- David Wilcox
- Benjamin ArmintorAndy Wagner
Agenda
- Release of 4.1.1?
- We will not be the goal of having the release done by the end of this week
- Goal (blocker) to have the blank node work in 4.1.1
- Michael Durbin will take the lead on getting the release out next week while Andrew Woods is at LDCX
- Release of 3.8.1?
- Islandora
- Upgration (migration-utils work)
- 3.8.1 branch pull requests need to be merged
- Testing needs to be done before the release
- Testing must be done by the community so we can actually release it.
- OR2015 is the agreed upon the deadline for testing.
- All pull requests will be merged into the 3.8.1-SNAPSHOT branch
- Release candidate and release candidate artifacts will be built from the 3.8.1-SNAPSHOT branch
- migration-utils
- Nick Ruest proposed a prioritization of migration functionality
- Traverse fcrepo file system (current primary focus)
- Migrate export context
- Archive export context
- Nick Ruest volunteered to create test fixtures migration-utils vm (fcrepo 3.x content and fcrepo4)
- Michael Durbin should have a preliminary solution in about a week, and Nick Ruest will be a guinea pig
- Nick Ruest proposed a prioritization of migration functionality
- Audit Service implementation options
- Audit Service call at 3pm EST today
- Focused on external triple-store
- Read: servicing queries
- Write: audit events (internal & external)
- Requirement: exposing external SPARQL endpoint
- Incorporate fcrepo-camel component
- Discussion around event ordering and who/what sends the message
- Combination of timestamps and users would alleviate this
- Old pivitol ticket about jcr namespaces being leaked that wasn't transferred over
- Unknown User (acoburn) to port old Pivitol ticket to JIRA (jcr namespaces being leaked)
- Discussion around event ordering and who/what sends the message
- Requirements can be met without a log of core fcrepo code updates
- Guiding principles
- Any Fedora4 feature should be available through an API which is an implementation of LDP or an optional extension (ideally an existing standard)
- Fedora4 features should favor existing tools over custom code
- Fedora4 features should establish integration patterns where an implementation is not a part of the core cod
- Further discussion on "pure" LDPRs : Design
- Discussion centralized on the wiki page
- Need to break proposals down, and not approve them all together
- Things that are less contentious
- server managed properties
- Things that are contentious
- non-container resources
- arbitrary RDF
- rdf interaction model and non-rdf interaction model
- Discussion centralized on the wiki page
- LDP and /fcr:versions
- We need to tighten up and clary (obscurities) where Fedora can do a better job with LDP
- New JIRA tickets
...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